From buildsys at fedoraproject.org Tue May 1 12:10:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 1 May 2007 08:10:37 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-01 Message-ID: <20070501121037.E3BD3152134@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 14 firmware-addon-dell-1.2.13-1.el5 NEW gmime-2.2.3-3.1.el5 NEW perl-Net-Netmask-1.9012-3.el5 NEW perl-TimeDate-1.16-4.el5 NEW php-pear-HTTP-Request-1.4.0-1.el5 NEW php-pear-Image-Canvas-0.3.0-3.el5 NEW php-pear-Image-Color-1.0.2-3.el5 NEW php-pear-Image-Graph-0.7.2-2.el5 NEW php-pear-Net-FTP-1.3.2-1.el5 NEW php-pear-Numbers-Roman-1.0.1-1.el5 NEW php-pear-Numbers-Words-0.15.0-2.el5 NEW php-pear-PHP-Compat-1.5.0-1.el5 NEW php-pear-PHP-CompatInfo-1.4.3-1.el5 NEW spambayes-1.0.4-4.el5 Packages built and released for Fedora EPEL 4: 1 firmware-addon-dell-1.2.13-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Axel.Thimm at ATrpms.net Tue May 1 13:18:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 15:18:14 +0200 Subject: Missing epel Message-ID: <20070501131814.GF10108@neu.nirvana> Hi, I will most probably not be able to make it to the meeting. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue May 1 13:40:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 01 May 2007 15:40:35 +0200 Subject: Packages from fc6 that are not part of rhel5 Message-ID: <46374353.7080003@leemhuis.info> Hi! Some packages that are part of FC6 are not included in RHEL5 afaics. Gmime, which I maintained in FE4 until it got moved to FC with Version 5, is one of those. I build it for EPEL5 today. I thought it might be helpful to compile a list of those packages that are part of FC6 but not included in RHEL5. You can find it below (I'll put it in the EPEL-FAQ in the wiki, too). Note: that list is compiled from src.rpm and thus sub-packages (gmime-devel, mono-*) are not mentioned in it. aqbanking autorun awesfx beagle bluez-pin bouncycastle cleanfeed concurrent cpufreq-utils cryptix cryptix-asn1 crypto-utils dbus-sharp dictd diskdumputils eclipse-bugzilla eclipse-cdt eclipse-changelog epiphany evolution-sharp fedora-logos fedora-release fedora-release-notes f-spot gecko-sharp2 genromfs gmime gnome-sharp gnome-vfs2-monikers gnucash gnu-getopt gsf-sharp gsl gtk-sharp2 gwenhywfar g-wrap hexedit iprutils ipvsadm isicom jessie jfsutils jgroups kdeedu krbafs libgdiplus libofx librtas libtirpc linux-atm lvm2-cluster mono mozplugger mysqlclient10 mysqlclient14 ncpfs netatalk netdump newt-perl nhpf nut openswan perl-Devel-Symdump perl-File-MMagic perl-Frontier-RPC perl-Inline perl-Parse-RecDescent perl-PDL perl-RPM-Specfile perl-TermReadKey perl-TimeDate pnm2ppa ppc64-utils puretls pychecker pydict reiserfs-utils rgmanager rwall selinux-doc slib system-config-cluster system-config-netboot tanukiwrapper timidity++ tomboy ttcp tvtime wordtrans xfsprogs xorg-sgml-doctools xorg-x11-docs xorg-x11-drv-amd xorg-x11-xdm yaboot Anyone interested in building those for EPEL? Especially having mono in EPEL might be nice to have. If you want to maintain one of those it should be enough to request a EPEL-branch if the package got reviewed already -- e.g. in the past for Extras of during the merge review. If it didn't get reviewed yet you IMHO should help with finishing the merge review fist before requesting a EPEL branch. Ohh, and it might be good to ask the current "Core" maintainer if he wants to maintain the package in EPEL himself before requesting the EPEL branch. CU thl From mailinglists at andreas-mueller.com Tue May 1 14:06:24 2007 From: mailinglists at andreas-mueller.com (Andreas Mueller) Date: Tue, 1 May 2007 16:06:24 +0200 Subject: Packages from fc6 that are not part of rhel5 In-Reply-To: <46374353.7080003@leemhuis.info> References: <46374353.7080003@leemhuis.info> Message-ID: <200705011606.25495@andreas-mueller.com> Thorsten Leemhuis wrote: > fedora-logos > fedora-release > fedora-release-notes I think those aren't needed in EPEL, but at least apt (which is in EPEL) requires fedora-release. I've just filed a bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238561 Should be easy to fix... Regards, Andreas From fedora at leemhuis.info Wed May 2 17:05:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 May 2007 19:05:46 +0200 Subject: topics for todays EPEL meeting Message-ID: <4638C4EA.20605@leemhuis.info> Hi all! Sorry, I was busy with other stuff and forgot to send the topics for todays meeting (17:00 UTC, #fedora-meeting) to the list in time. Nevertheless here they are: /topic EPEL Meeting -- chairmen /topic EPEL Meeting -- mass rebuild for RHEL5 /topic EPEL Meeting -- shortcut for branching -- dgilmore? /topic EPEL Meeting -- repotags/interaction with 3rd party repos /topic EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid Anything else I forgot? CU thl From rdieter at math.unl.edu Wed May 2 18:47:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 May 2007 13:47:20 -0500 Subject: Proposal: Repository Community Collaboration Statement References: <4634A1A8.7070903@timj.co.uk> Message-ID: Tim Jackson wrote: ... > Basically: > is this something that people feel could form the basis of something > they'd be willing to sign up to? Or should we all just go back to > arguing about repotags? > > --------------------------------------------------------------------- > Repository Community Collaboration Statement > --------------------------------------------------------------------- +1000000! Fantastically awesome, imho. Extracted and wiki-ized at: http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration -- Rex From cmc at math.hmc.edu Wed May 2 23:19:49 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Wed, 02 May 2007 16:19:49 -0700 Subject: topics for todays EPEL meeting In-Reply-To: <4638C4EA.20605@leemhuis.info> References: <4638C4EA.20605@leemhuis.info> Message-ID: <32575.1178147989@vosill.math.hmc.edu> "TL" == Thorsten Leemhuis TL> Hi all! Sorry, I was busy with other stuff and forgot to TL> send the topics for todays meeting (17:00 UTC, TL> #fedora-meeting) to the list in time. Nevertheless here TL> they are: Oh, bugger, I wanted to try to participate. Are we actually getting most (or at least a representative subset) of the active participants from the lists in these meetings? From previous discussions (notably on the repotags issue), I've gotten the feeling that not all opinions from the list are being represented in the IRC meetings, and that decisions are being made that don't necessarily represent the whole range of participants or potential participants. Also, some of the topics aren't ringing a bell from list messages -- presumably the results of any discussions will be brought back to the list for further comment? Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri May 4 03:39:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 3 May 2007 23:39:35 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-03 Message-ID: <20070504033935.B8F8F152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 8 NEW dbmail-2.2.4-4.el5 NEW koji-1.1-2.el5 NEW mail-notification-4.0-2.el5 NEW php-pear-Math-Stats-0.9.0-0.1.beta3.el5 NEW php-pear-Net-Curl-1.2.3-2.el5 NEW php-pear-Net-POP3-1.3.6-2.el5 NEW pigment-0.1.5-1.el5 puppet-0.22.4-1.el5 Packages built and released for Fedora EPEL 4: 1 puppet-0.22.4-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Fri May 4 04:36:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 06:36:57 +0200 Subject: Mass rebuild in EPEL5 starting on Sunday Message-ID: <463AB869.4060006@leemhuis.info> Hi all! In the last EPEL Sig Meeting on Wednesday we agreed to mass rebuild all arch packages in EPEL5 that were build before RHEL5-final was installed on the servers. I'll take care of that and will likely start on Sunday European time to use a script that adds a ".1" to %release of all packages that need a rebuild. After that I'll commit the changes, tag and request a build. If you want to rebuild your packages yourself please do so in the next 52 hours! tia! CU thl From buildsys at fedoraproject.org Fri May 4 12:09:33 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 4 May 2007 08:09:33 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-04 Message-ID: <20070504120933.4BD54152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 2 NEW WindowMaker-0.92.0-10.el5 NEW libuninameslist-0.0-7.20060907.el5 Packages built and released for Fedora EPEL 4: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Fri May 4 17:20:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 19:20:37 +0200 Subject: Summary from this weeks EPEL meeting Message-ID: <463B6B65.9060205@leemhuis.info> = Meeting 20070404 = == Attending == >From the Steering Committee: * knurd (formally known as thl) * mmcgrath * nirik * quaid * stahnma Other contributors that joined the meeting: * rdieter, smooge == Summary == * chairmen: stahnma (who was one of the two that were proposed for the job) suggested to make knurd (the other one) become the organizational leader . knurd suggested to make stahnma kind of "vice-president" so there is one that will run the meetings or other stuff in case knurd is away. Knurd further mentioned that we can always fire the chairmen at any point if we like to. It was a agreed to be fairest to announce that a vote is forthcoming; so we'll try the wiki vote for that. * mass rebuild for RHEL5 : we do what was discussed in the past already. All arch packages that were not build against RHEL5 final will be mass-rebuild. Knurd will take care of that; that includes announcing that plan and doing the actual cvs updates and built requests. * shortcut for branching -- dgilmore was not around, so topic was skipped * Communication plan for enterprise customers/ISVs/IHVs -- stahnma: "I have been waiting to get more packages into the repo "; some more discussion around this; we revisit that in a later meeting * under that topic there were some discussion about co-maintainership and writing a template-mail that EPEL contributors could use to ask Fedora Contributors if they want to maintain their packages in EPEL; * what is in the way of EPEL repo opening / when's our announcement? (topic came up during the meeting): knurd gave this list: * finish the rebuild * final repo layout * finish the wiki (e.g. remove the not-finished warnings) * make sure everything works * announce bodhi might be helpful or even needed for the final repo layout; bodhi might make formal QA policies (smooge raised that topic and will see if he can get something written up regarding QA polices) possible as well. bodhi is in the process of getting finished, but no ETA yet ("hopefully soon") * repotags/interaction with 3rd party repos ; people want to get rid of that topic, but we have to face it. See full log (starting at 0:39) for details. knurd will try to get that topic discussed again on the list to get opinions how to mopve on from Contributors inside or outside of EPEL. == Full Log == {{{ 00:00 --- | knurd has changed the topic to: EPEL meeting 00:00 < knurd> | ping stahnma quaid mmcgrath nirik dgilmore -- who's around? 00:01 * | stahnma is here 00:01 < mmcgrath> | I'm here 00:02 < mmcgrath> | also working on the merge though so I'll be a litle quiet 00:02 < knurd> | mmcgrath, thx for your work on the merge ;-) 00:03 < knurd> | well, three people is not much 00:03 < knurd> | I'd say we wait 10 minutes for other to show up 00:03 < knurd> | or cancel the meeting if no one shows up 00:03 < mmcgrath> | we cancelled last week too. 00:03 < quaid> | knurd: oi! 00:03 < mmcgrath> | The list has been pretty quiet 00:03 < stahnma> | again, I will mention that mid-day in the US is hard to meet on 00:03 < knurd> | mmcgrath, I know :-/ 00:04 * | quaid is here and can find something to talk about ;-D 00:04 < knurd> | stahnma, US evenings is hard for europe 00:04 < stahnma> | understand...maybe US early mornings? 00:04 < knurd> | quaid, makes four people now 00:04 < stahnma> | quarum? 00:04 < quaid> | mid-day is the hardest when one is not allowed to use IRC at work 00:04 * | stahnma will be in that boat soon :( 00:04 < knurd> | stahnma, maybe 00:04 < quaid> | s/ar/or/ 00:04 < quaid> | stahnma: :( 00:04 * | rdieter sits in the rabble seats. 00:05 < quaid> | stahnma: what's hard is there are always ways around, but then one is breaking the rules and that's a lame spot to be in 00:05 * | bpepple pokes his head in to look around. 00:05 < stahnma> | yeah, that's kind of what I do now 00:05 < stahnma> | but they are probably going to block out-bound ssh 00:05 < stahnma> | :( 00:05 < stahnma> | they already block outbound IRC here 00:05 < rdieter> | use port 80. :) 00:06 < stahnma> | right on 00:06 * | knurd would rellay like if either dgilmore or nirik would show up 00:07 < bpepple> | isn't dgilmore still in Australia? 00:07 < stahnma> | no, he's back 00:07 < mmcgrath> | He's said he won't be around much for a bit. 00:07 < knurd> | mmcgrath, yeah, that's what I told me, too (iirc) 00:07 < stahnma> | true, shall we commence? 00:07 < quaid> | rock on 00:08 < knurd> | stahnma, yeah 00:08 * | nirik is back. Was trying to get iwlwifi working. 00:08 --- | knurd has changed the topic to: EPEL Meeting -- chairmen 00:08 * | knurd welcomes nirik 00:08 < knurd> | that makes five people, that should be better than just four 00:08 < knurd> | so, let's get started 00:09 < knurd> | the chairmen stuff is lingering around for weeks now 00:09 < knurd> | shall we vote one 00:09 < knurd> | or get rid of that idea 00:09 < knurd> | I think we agree already to have one 00:09 < knurd> | that correct? 00:09 --> | entr0py (Bernard Johnson) has joined #fedora-meeting 00:09 < stahnma> | I think we voted to have one 00:09 < nirik> | I suppose. I like the idea of someone taking point on organizing things... 00:10 < stahnma> | so , I think we have knurd become the organizational leader 00:10 < mmcgrath> | +1 to having one 00:10 < stahnma> | unless everyone wants to vote, I am willing to just have knurd do it 00:10 < knurd> | stahnma, thx for your support; do you want to be vice-president or something like that? 00:10 < knurd> | and run the meetings when I'm afk? 00:10 < stahnma> | since I was the only other runner, I think it's fine... 00:10 < stahnma> | I can be a backup 00:10 < stahnma> | I need no formal title 00:10 <-- | Southern_Gentlem has left #fedora-meeting ( "Leaving") 00:11 < knurd> | so how do we vote this? 00:11 < knurd> | anyone else besides me then that want to run for the chairmen job? 00:11 < quaid> | I like this idea because stahnma presents less controversial of a stance than knurd has, so it gives a balance. 00:12 < quaid> | maybe stahnma can focus on the neutral ground when we have conflicts :) 00:12 < knurd> | and, as we discussed already, we can always fire the chairmen at any point if we like 00:12 < quaid> | still though ... 00:12 <-- | giallu has quit (Read error: 110 (Connection timed out)) 00:12 < quaid> | would be fairest to announce that a vote is forthcoming 00:12 < quaid> | and have it following the announcement 00:13 < knurd> | quaid, sounds good 00:13 < knurd> | wiki vote or just next meeting? 00:13 < nirik> | yeah, perhaps give folks that can't attend a chance to vote? 00:13 < stahnma> | I am fine with that too, I just wnat to move on to working on epel, not the working on the people who work on epel 00:13 < nirik> | (or ratify, or whatever) 00:13 --- | SmootherFrOgZ__ is now known as SmootherFrOgZ 00:13 < quaid> | well, wiki vote is ok, since an IRC vote isn't anonymous either 00:14 < quaid> | yeah, ratify 00:14 * | nirik also would like to see us move on to doing things rather than talking about how we talk about doing things. 00:14 < knurd> | nirik, +1 00:14 < knurd> | k, I'll put it up in the wiki 00:14 < quaid> | I suggest we throw up a Wiki ratification, and move forward from this moment as if the ratification has happened; if we have to back-track on it later, we can 00:14 < quaid> | so, nirik +1 :) 00:15 < knurd> | and then can get that solved over the next few days until next weeks meeting 00:15 < stahnma> | ok 00:15 < nirik> | yeah, that sounds good. 00:15 < quaid> | cool, now we can talk about what is in the way of EPEL repo opening 00:15 < knurd> | k; anything else regarding the chairmen stuff? 00:15 --> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:15 < stahnma> | none here 00:16 --- | knurd has changed the topic to: EPEL Meeting -- mass rebuild for RHEL5 00:16 < knurd> | quaid, I'll keep that in mind 00:16 < knurd> | so, do we care about hte mass rebuild 00:16 < knurd> | seem or do we simply ignore the rest 00:16 < knurd> | lots of pacakges were not rebuild yet afaics 00:17 < nirik> | we should mass rebuild all the not rebuilt arch ones... 00:17 < nirik> | I think we need dgilmore for that tho. 00:17 < stahnma> | probably 00:17 < knurd> | nirik, no, everyone can do that 00:17 < knurd> | I can do that, as long as the buildsys is working 00:17 < knurd> | and that might not be the case in the next days 00:18 < nirik> | although should we put the repotag thing to bed first? 00:18 < knurd> | so let's say this: 00:18 < knurd> | we give people until sunday to rebuild their arch packages 00:18 < knurd> | and then I'll rebuild every arch package that didn't get build on RHEL5 00:18 < nirik> | knurd: +1 00:18 < knurd> | by adding a ".1" to release of them 00:19 < knurd> | then tagging, building, done 00:19 < knurd> | stahnma, quaid, mmcgrath, does that sound sne to you? 00:19 < knurd> | sane 00:19 < stahnma> | sounds fine to me 00:19 < mmcgrath> | Yeah that seems reasonable. 00:20 < knurd> | that makes 4 +1 (including mine) 00:20 --> | cweyl_ (Chris Weyl) has joined #fedora-meeting 00:20 * | knurd will wait 15 seconds for quaid's opinion before moving on 00:20 --- | cweyl_ is now known as cweyl|work 00:20 < knurd> | k, settled even without quaid 00:20 < quaid> | good for me :) 00:20 < knurd> | hah 00:20 < knurd> | makes 5 x +1 00:21 < knurd> | settled 00:21 < knurd> | anything else regarding the rebuild? 00:21 --- | knurd has changed the topic to: EPEL Meeting -- shortcut for branching -- dgilmore? 00:21 < knurd> | dglimore not around, skipping 00:21 --- | knurd has changed the topic to: EPEL Meeting -- Communication plan for enterprise 00:21 --- | knurd has changed the topic to: EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid 00:21 < knurd> | any news on that one? 00:22 < stahnma> | not much. I have been waiting to get more packages into the repo 00:22 < knurd> | k 00:22 < stahnma> | right now, not a ton of value lives inside of epel from a customer prospective 00:22 < mmcgrath> | A plan is good 00:22 < mmcgrath> | but we need to focus on being live first :) 00:22 < stahnma> | identifying the packages in core and not rhel was good 00:22 < mmcgrath> | when's our announcement? 00:22 < knurd> | stahnma, shall we revisit it in four weeks or so? 00:22 < knurd> | mmcgrath, I'll make that the next topic 00:22 < mmcgrath> | 00:22 < stahnma> | well, I think we could bring it up each week, just might be quick :) 00:23 < knurd> | stahnma, okay, we'll see 00:23 < knurd> | I'll move on now 00:23 < stahnma> | I would like to get a template for us requested packages to branched 00:23 < stahnma> | from othe rextras developers 00:23 < quaid> | yeah, I've recently gained what little authority I need to approach more folks in RH, such as Marketing, so that helps 00:24 --- | dwmw2 is now known as dwmw2_gone 00:24 * | quaid is always two lines beind, it seems :) 00:24 < knurd> | stahnma, that what the " shortcut for branching" was meant for 00:24 < stahnma> | ahh 00:24 * | stahnma didn't quite realize that's what that was 00:24 < knurd> | stahnma, we need somethign easy for CVS admins and Fedora Contributors 00:24 < knurd> | to request EPEL branches 00:24 < quaid> | request or request to maintain? 00:24 < stahnma> | we also need to know who won't for whatever request epel branches and find co-maintainers 00:25 < knurd> | quaid, request 00:25 < quaid> | ah, and its up to the maintainer to say if they don't want to maintain one 00:25 < quaid> | which then opens up a co-maintainer to come in and do it? 00:25 < quaid> | is the concern people feeling co-maintainers forced upon them? 00:25 < quaid> | "I don't want a team, I work best alone" 00:26 < knurd> | quaid, then the contributor has to take care of epel 00:26 < knurd> | he can't stop a co-maintainer if he doesn't want to do epel himself 00:26 < knurd> | that was decided by FESCo in the past already iirc 00:26 < knurd> | and is part of the co-maintainer policy 00:26 < quaid> | ok, just making sure I got the distinction right, thx 00:27 * | quaid approves, it makes sense; after all upstream can't stop us from packaging for Fedora, right? 00:27 < knurd> | stahnma, writing a "do you want to maintain your pakage foo in EPEL" template mail might be helpful 00:27 < knurd> | stahnma, was that what you were up to? 00:27 < knurd> | then I#d say: just go for it and put it in the wiki 00:27 < stahnma> | yeah 00:28 < knurd> | stahnma, to http://fedoraproject.org/wiki/EPEL/ContributorStatus properly 00:28 < knurd> | that makes most sense afaics 00:28 * | knurd will move on to next topic soon if that okay for everyone 00:29 < mmcgrath> | 00:29 --- | knurd has changed the topic to: EPEL Meeting -- what is in the way of EPEL repo opening / when's our announcement? 00:29 < knurd> | my 2 cent: 00:29 < knurd> | - finish the rebuild 00:29 < knurd> | - final repo layout 00:30 < knurd> | - finish the wiki (e.g. remove the not-finished warnings) 00:30 < knurd> | - make sure everything works 00:30 < knurd> | - annouce 00:30 < knurd> | - 00:30 < knurd> | did I miss anything important? 00:30 < mmcgrath> | Looks good to me. 00:30 < mmcgrath> | so we're blocking heavily on dgilmore 00:30 < knurd> | likely :-/ 00:30 < knurd> | we need a second dglimore 00:31 < mmcgrath> | Hell we could use a more than that :) 00:31 < knurd> | I tried cloning jeremy already, but It does not work 00:31 < nirik> | are we also waiting on bodi? or at least push scripts that can do testing? 00:31 < knurd> | I need to try better 00:31 < knurd> | maybe then we can clone both jeremy and dgilmore 00:31 < mmcgrath> | nirik: We're waiting on bodhi but I don't think the announcement has to block on it. 00:31 < knurd> | nirik, that's part of the "final repo layout" step in my listing 00:32 < mmcgrath> | ahh, so it is a blocker. 00:32 < mmcgrath> | lmacken: ping? 00:32 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:32 < knurd> | maybe we need to find a interrim solution 00:32 < nirik> | can we now manually push to testing and only after release people want push to release? 00:32 < knurd> | nirik, something like that maybe, yet 00:32 < smooge> | Do you have a plan on which EL's you are supporting with what.. and how you are going to test beyond 'it compiles and doesnt core dump when we run it?' 00:32 < knurd> | yes 00:32 < nirik> | if it can be done with current push scripts manually for now, I think we can go on without bodi... 00:32 < knurd> | smooge, not that I'm aware off 00:33 < knurd> | nirik, I hope so 00:33 <-- | viking-ice has left #fedora-meeting ( "Leaving") 00:33 < nirik> | smooge: I don't think there is a formal qa battery yet... but we have a criteria for what goes into testing/release and when... 00:33 < knurd> | smooge, want to write something? 00:34 < lmacken> | mmcgrath: pong 00:34 < nirik> | http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates 00:35 < knurd> | nirik, that should be a start 00:35 < knurd> | nirik, but we probably need more formal QA guidelines sooner or later 00:35 < knurd> | but I tend to say it's fine if we start without them 00:35 < nirik> | yeah, and we can add to that... like 'X number of +1's from testers... etc' 00:36 < nirik> | or 'any -1's from a tester, package is held until thats addressed, or whatever. 00:36 < knurd> | with requires bodhi afaics :-/ 00:36 < mlum_thud> | hey folks, might be off-topic; can I modify the CVSROOT/modules file to contain more concise component aliases? at present, we just checkout our entire repository :o 00:36 < mmcgrath> | lmacken: any updates on bodhi? 00:36 < mlum_thud> | mmcgrath/f13: or should I ask someone else? 00:36 < smooge> | knurd, I would probably hold things back at the moment in trying to write it.. I will try to help out nirik since he/she seems to have already doen work on it 00:36 < knurd> | mlum_thud, #fedora-devel might be the better channel atm 00:36 < nirik> | smooge: I didn't do that doc, knurd did. ;) 00:36 < knurd> | mlum_thud, or #fedora-admin 00:37 < mlum_thud> | thanks guys. 00:37 < knurd> | smooge, there are probalby still weeks before the official annoucement of EPEL 00:37 < knurd> | smooge, so we can revisit it next week 00:37 < lmacken> | bodhi is able to {,un}push updates to testing/final and such. I have a test instance up at http://publictest2.fedora.redhat.com (guest/guest), and have semi-configured EPEL. I still need to make sure it matches the proposed repo layout and I need to tweak how update announcements are generated for things other than fedora 00:37 < knurd> | smooge, shall we? 00:37 < knurd> | mlum_thud, thx mlum_thud 00:38 < knurd> | lmacken, any ETA when it goes into production? 00:38 < lmacken> | I have yet to read the PackageMaintenanceAndUpdates policy for EPEL, so I'm not sure if it meets it yet.. 00:38 < nirik> | lmacken: cool. you rock. ;) 00:38 < knurd> | yeah lmacken, you rock ;) 00:38 < smooge> | I need to write up something for CentOS qa so i will try to make it applicable for both items. 00:38 < lmacken> | knurd: hopefully soon.. i'm going to work on the production instance of it tonight and later this week 00:38 < lmacken> | thanks :) 00:38 < knurd> | lmacken, sounds good 00:38 < knurd> | smooge, sounds good as well :) 00:39 --> | MauricioPretto (hash) has joined #fedora-meeting 00:39 < knurd> | k, anything else or shall I move on? 00:39 --- | knurd has changed the topic to: EPEL Meeting -- repotags/interaction with 3rd party repos 00:39 < smooge> | I will also pass it by Dag to see if it can help the forge (these are my primary focuses.. I am here to try and observe for CentOS meeting) 00:40 < nirik> | smooge: excellent. 00:40 < knurd> | well, did everyone saw what I send to fedora-devel? 00:40 < knurd> | opinions? 00:40 < mmcgrath> | I hate that repotag has been coupled with interactions with 3rd party repos. 00:40 < stahnma> | I am growing quite tired of repotag-theory 00:40 < mmcgrath> | It seems to imply if we don't use a repo tag, we hate 3rd party repos. 00:40 < knurd> | mmcgrath, agreed... 00:41 < knurd> | stahnma, +1 00:41 < nirik> | I think repotags are a poor answer for something that should be fixed in yum/rpm 00:41 < knurd> | nirik, +1 00:41 < smooge> | I will put in a different point of view on interactions with 3rd party repos. 00:41 < nirik> | I suppose repotags could be just done now to make other repos happy and we can remove them later when yum/rpm can get fixed? 00:42 < lmacken> | (whoever just tried pushing update in bodhi: i had to wipe out the updates-stage earlier today due to space issues, so it probably didn't work :) 00:42 < knurd> | nirik, that was part of my plan I send to fedora-devel 00:42 < nirik> | knurd: right. 00:42 < smooge> | This may be the rent money of other people... and people get extremely defensive about when their next paycheck is involved. 00:42 < knurd> | wwthe question is: do we want to discuss the plan further? 00:43 < stahnma> | I don't *want* to, but probably we should come to some sort of agreement 00:43 < knurd> | well, we basically have two options 00:44 < knurd> | a) stick to "no repotags" 00:44 < knurd> | b) evaluate them again, in the hope to find a solution htat makes people happy 00:44 < smooge> | c) work on an upstream technical fix to yum/rpm 00:44 < knurd> | I'd really like to go for "a", but nevertheless I prefer "b" for now 00:44 < knurd> | smooge, that's part of "b" for me ;-) 00:45 < knurd> | as we can those fixes only in for future dists 00:45 < nirik> | it's likely gonna be a while before we could get yum/rpm fixed. ;( 00:45 < knurd> | nirik, that, too 00:45 < mmcgrath> | I vote A). I don't think this is worth any more of our time. 00:45 < knurd> | a=1 b=1 00:46 < knurd> | stahnma, quaid, nirik ? 00:46 < knurd> | or someone from the rabble seats? 00:46 < knurd> | or shall I simply ask on the list? 00:46 < nirik> | well, I think b) is really: do them now, and then perhaps someday remove them. 00:47 < knurd> | nirik, agreed 00:47 < nirik> | I would have to say A) as well... this is a big energy sapping discussion that keeps going on and on... 00:47 <-- | mether has quit (Read error: 104 (Connection reset by peer)) 00:47 < smooge> | Rabble-rouser 0.1 vote for B. Not because of whining, but because it was an unwritten rule of the playground before everyone took their balls home 00:47 < nirik> | I would be ok with asking on the list and saying: vote. +1 or -1. 00:48 < nirik> | (to try and bypass further discussion) 00:48 < stahnma> | hmm 00:48 < stahnma> | I vote c 00:48 < knurd> | c? 00:48 < knurd> | stahnma, you mean "work on an upstream technical fix to yum/rpm 00:48 * | entr0py still likes the idea of stuffing the information in the Vendor tag 00:48 < knurd> | stahnma, as I said, that part of "b" IMHO 00:49 < knurd> | stahnma, and what I wrote to fedora-devel 00:49 < stahnma> | oh ok 00:49 --> | mether (Rahul Sundaram) has joined #fedora-meeting 00:49 < nirik> | well, I think we can do c) no matter what... 00:49 < stahnma> | sorry, (half working) 00:49 < knurd> | well, I'll get to the list with it 00:49 < stahnma> | then I vote b -> c 00:49 < knurd> | no vote on the list 00:49 < nirik> | I would love to see it fixed 00:49 < knurd> | just collecting opinions 00:49 < knurd> | and then we'll decide 00:49 < smooge> | If we can get yum-preferences upstream or better documented it would help the problem from a technical point 00:49 < knurd> | does that sound sane? 00:49 < knurd> | yum-preferences? 00:50 * | knurd googles 00:50 < nirik> | knurd: sounds good. 00:50 < knurd> | google doesn't return anything useful 00:50 < smooge> | It is a way to say I give preference to repository X over Y. This solves the I have clamav from atrpms and it overwrote my rpmforge one 00:50 < nirik> | smooge: is that a theoretical plugin to do what we want? 00:50 < knurd> | stahnma, quaid, mmcgrath are you fine if we ask for opinions on the list? 00:51 < stahnma> | I am fine, but I feel like we have done it a few times 00:51 < smooge> | let me get the correct name 00:51 < stahnma> | and we have a near holy-war on 00:51 < smooge> | sorry yum-priorities.noarch 00:51 < mmcgrath> | I feel the same as stahnma 00:51 < nirik> | smooge: right. It could also show 'repo X' when something fails with a package. 00:51 < knurd> | nirik, +1 00:51 < knurd> | smooge, mmcgrath, I agree, but this has become political 00:52 < knurd> | the current situation is quite bad for us already 00:52 < knurd> | maybe it will get even worse 00:52 < mmcgrath> | knurd: quite bad for the 300+ extras developers or the 6,7 3rd party developers? 00:52 * | quaid is fine for list opinions 00:52 < nirik> | smooge: oh, it's exists. Way cool. 00:52 < knurd> | mmcgrath, for the fame of epel imho 00:52 < smooge> | mmcgrath, I doubt 300 extra developers are going to sign up for supporting their packages for 7 years 00:54 < knurd> | k, so how to move on? 00:54 < mmcgrath> | knurd: whats the easiest way so that I don't have to hear about repo tags ever again? Add them? 00:54 < nirik> | we have 58 in owners.epel.list 00:54 < stahnma> | mmcgrath: probably 00:54 < knurd> | mmcgrath, likely 00:54 < knurd> | mmcgrath, but that will be a fight inside the Fedora fenceline, too 00:54 < knurd> | I assume 00:55 --- | stickster is now known as stickster_afk 00:55 < stahnma> | if it adds no burden to a packager, I guess I don't see what the complaining is about 00:55 < mmcgrath> | I'm just tired of playing politics with people who are trying to define what rules we play by even though they don't honor our rules. 00:55 < knurd> | stahnma, "no burden" is important IMHO 00:55 < mmcgrath> | I mean hell, how many of those 3rd party repos have even signed a cla? 00:55 < mmcgrath> | We're aiming much larger then they are and we have a much different structure as a result. 00:56 < knurd> | mmcgrath, I don't think such words help to solve the problems at hand; they might make them worse... 00:56 < mmcgrath> | I'm not a politician. I'm a technician. 00:56 < knurd> | :-) 00:57 < knurd> | so, what do to 00:57 < mmcgrath> | I'll obstain. 00:57 < knurd> | a) discuss next week again 00:57 < knurd> | b) ask the list 00:57 < knurd> | c) ? 00:57 < stahnma> | boo for a 00:57 < stahnma> | perhaps just add them until the techincal problem is solved 00:57 < stahnma> | so, yeah ask list 00:57 < stahnma> | I guess 00:57 * | stahnma really wants this battle over 00:57 < smooge> | why is there a problem? Egos, identity, and paycheck/livelihood. 00:57 < knurd> | stahnma, that's not so easy and will be a bit or work, too 00:58 < knurd> | +1 for b btw 00:58 < knurd> | then let's see how things envolve over the next days 00:58 < knurd> | and then we'll see how to move on 00:58 < stahnma> | knurd: true, I feel like this is stopping a lot of progress. Maybe it's just my feelings, but I would love to get past this and start working on good stuff 00:58 < knurd> | does that sound sane? 00:58 < stahnma> | sure does 00:58 < knurd> | stahnma, +1 00:58 < mmcgrath> | it's a distraction, nothing more. 00:59 < knurd> | mmcgrath, maybe, but we have to deal with it afaics 00:59 < knurd> | it was forced on us 00:59 < nirik> | if we are going to add them, we should before the mass rebuild.. so we don't have to rebuild again. 00:59 < nirik> | so decision from list before sunday? 00:59 < knurd> | k, I'll go to the list then over the next few days with it if nobody yells soon 00:59 < knurd> | nirik, that's impossible 00:59 < stahnma> | nirik strikes with logic 01:00 < knurd> | we need buy in from FPC and other groups if we want to add repotags 01:00 < knurd> | that might take *weeks* 01:00 < smooge> | actually, I would say you forced it on yourself. Repositories are as much like distributions. People choose their 'flags' and stick with them 01:00 < knurd> | nirik, and the rebuild is about arch packages only 01:00 < stahnma> | even if we decide to do it, won't fpc or fesco just remove it? 01:00 < stahnma> | or likely remove it? 01:00 < knurd> | stahnma, It's a decisions EPEL, FESCo, and FPD need to do together afaics 01:01 < knurd> | mabye we even need the board 01:01 < stahnma> | I guess, if the EPEL people are not empowered to make it, can we have the pro-repotaggers take it up there 01:01 < stahnma> | and allow epel to progess? 01:01 < stahnma> | I am asking becuase I don't quite understand the inner-workings of who is authoritative over whom on what issues 01:02 < knurd> | stahnma, we have no real pro-repotaggers besides thimm 01:02 < stahnma> | well, there are others on list 01:02 < knurd> | most of them are outside of fedora 01:02 < stahnma> | jsut not on the epel SIG committiee 01:02 < stahnma> | ah 01:02 < mmcgrath> | but none that own any packages. 01:02 * | knurd has to leave in less than three minutes 01:03 < knurd> | so, shall I go to the list with it asking for opinions? 01:03 < knurd> | +1 for list from me 01:03 < stahnma> | yes 01:03 < nirik> | sure, but at some point I would really like a decision to "stick" so we don't have to keep discussing each week. ;) 01:03 * | mmcgrath wonders what we could have gotten one in the last many weeks. 01:03 < knurd> | nirik, +100 01:04 < knurd> | k, I'll go to the list then 01:04 < knurd> | anything else? 01:04 * | knurd will close the meeting in 30 01:04 < smooge> | ok here is a hypothetical question 01:05 * | knurd will close the meeting in 15 01:05 < mmcgrath> | smooge: ? 01:05 < smooge> | never mind 01:05 < knurd> | smooge, sorry, let's close the meeting now 01:05 * | nirik adds a RFE to the repoman review about supporting plugins and priorities. 01:05 < knurd> | smooge, but feel free to share your opinion 01:05 < knurd> | I have to leave now 01:05 < knurd> | stahnma, can you close the meeting maybe? 01:05 < knurd> | I'll write the minutes 01:05 < stahnma> | if I knew how to close I would (I'm new here) 01:06 < nirik> | smooge: also, feel free to continue discussions in #epel... usually a number of folks there lurking. 01:06 < knurd> | nirik, +1 01:06 * | knurd will close the meeting in 15 01:06 --- | knurd has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting 01:06 < knurd> | -- MARK -- Meeting end }}} From fedora at leemhuis.info Sat May 5 09:45:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 May 2007 11:45:50 +0200 Subject: topics for todays EPEL meeting In-Reply-To: <32575.1178147989@vosill.math.hmc.edu> References: <4638C4EA.20605@leemhuis.info> <32575.1178147989@vosill.math.hmc.edu> Message-ID: <463C524E.5020404@leemhuis.info> C.M. Connelly schrieb: > "TL" == Thorsten Leemhuis > TL> Hi all! Sorry, I was busy with other stuff and forgot to > TL> send the topics for todays meeting (17:00 UTC, > TL> #fedora-meeting) to the list in time. Nevertheless here > TL> they are: > Oh, bugger, I wanted to try to participate. Apologies again for sending it so late. I normally try to send them at least 24 hours before the meetings. But keep in mind that the meetings ATM have a fixed date and time: each Wednesday at 17:00 UTC (18:00 UTC during winters). > Are we actually getting most (or at least a representative subset) > of the active participants from the lists in these meetings? No. In most cases there are the people from the Steering Committee around and two or three other contributors. But the meeting is open, so everybody can join in (which is important). And I'd really like it if more people would be around. But such low "community participation" is kind of "normal" afaics. Fedora Extras had 250 - 300 contributors, but in the open FESCo meetings only 2 - 5 non-FESCo memebers participate normally. > From previous discussions (notably on the repotags issue), I've > gotten the feeling that not all opinions from the list are being > represented in the IRC meetings, and that decisions are being made > that don't necessarily represent the whole range of participants > or potential participants. Well, it are open meetings and people can join if they want to make sure their opinion gets representated. But the meetings are IMHO not for discussing each and every detail anew. That in my experiences does not work on IRC -- that what we IMHO should use the list for. Further: Fedora (and EPEL) is a community project. But there is no single community voice -- everyone has different expectations and opinions, so we all sometime have to live with decisions that we don't like. See the current "FC7 Zope" thread on fedora-devel-list -- I think it's a big mistake that FESCo decided to remove Zope because it doesn't want a older python-version in Fedora 7; I raised my concerns on the list, but it seem it won't change. So I have to live with the decision FESCo did. If I can't I'm free to leave. > Also, some of the topics aren't ringing a bell from list messages > -- presumably the results of any discussions will be brought back > to the list for further comment? I run the meetings often and I always try to make sure everything important get discussed on the list before it gets decided/voted. That way everyone can express his or her opinions; those will influence the opinions of those that have to do the decision. We of course could try to use a more "base" approach and let all contributors influence decisions via a kind of voting app. This was discussed in the past in Fedora-land, but sometimes things that are popular (and thus have good chances getting lots of votes) are not always the best ones. That's why in Fedora lots of different committees, that hopefully consists of members that try to find a balance between "good" and "popular". CU knurd From fedora at leemhuis.info Sat May 5 11:43:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 May 2007 13:43:07 +0200 Subject: proposed vote for the Steering Committee members: Elect a chairmen Message-ID: <463C6DCB.80805@leemhuis.info> Hi! As discussed and decided in recent EPEL Steering Committee meeting we want to elect a chairmen for the EPEL Steering Committee. It was further agree upon to use a wiki-vote for the actual election. I actually prepared that wiki-vote now; see http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting or below for details. That okay for everybody? Cu thl ---- === Elect a chair === In recent (during April/May 2006) EPEL SIG Meeting it was decided to have one person to act as chairmen for the EPEL Steering Committee. During the discussions both stahnma and knurd (formally known as thl) were nominated for that position and showed willingness to act as chairmen; there were no other (self-)nominations for that job. When the actual vote come closer stahnma suggested to make knurd become the chairmen. knurd suggested to make stahnma kind of "vice-president", so there is one that will run the meetings or other stuff in case knurd is away. That is the proposed scheme this vote is about. Site notes: The chairmen will get the position for the same timeframe as the steering committee has a mandate; e.g until end of September. But we can always "fire" the chairmen at any point if we like to. Voting period: 20070506 UTC 12:00 until 20070508 UTC 11:59 ---- From buildsys at fedoraproject.org Sat May 5 14:36:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 5 May 2007 10:36:51 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-05 Message-ID: <20070505143651.D1B98152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 9 dircproxy-1.2.0-0.6.beta2.el5 NEW fontforge-20061025-2.el5 ganglia-3.0.4-3.el5 NEW isic-0.07-2.el5 libconfuse-2.5-4.el5 numpy-1.0.1-2.3.el5 powerman-1.0.25-3.el5 rrdtool-1.2.23-3.el5 NEW wine-0.9.36-2.el5 Packages built and released for Fedora EPEL 4: 2 NEW libuninameslist-0.0-3.20060907.el4 rrdtool-1.2.23-3.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From mastahnke at gmail.com Sat May 5 14:53:52 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 5 May 2007 09:53:52 -0500 Subject: proposed vote for the Steering Committee members: Elect a chairmen In-Reply-To: <463C6DCB.80805@leemhuis.info> References: <463C6DCB.80805@leemhuis.info> Message-ID: <7874d9dd0705050753s314169f8ia9238054b0ed4ef0@mail.gmail.com> On 5/5/07, Thorsten Leemhuis wrote: > Hi! > > As discussed and decided in recent EPEL Steering Committee meeting we > want to elect a chairmen for the EPEL Steering Committee. It was further > agree upon to use a wiki-vote for the actual election. > > I actually prepared that wiki-vote now; see > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting > or below for details. That okay for everybody? > > Cu > thl > ---- > === Elect a chair === > > In recent (during April/May 2006) EPEL SIG Meeting it was decided to 2007 even :) > have one person to act as chairmen for the EPEL Steering Committee. > During the discussions both stahnma and knurd (formally known as thl) > were nominated for that position and showed willingness to act as > chairmen; there were no other (self-)nominations for that job. > > When the actual vote come closer stahnma suggested to make knurd become > the chairmen. knurd suggested to make stahnma kind of "vice-president", > so there is one that will run the meetings or other stuff in case knurd > is away. That is the proposed scheme this vote is about. > > Site notes: The chairmen will get the position for the same timeframe as > the steering committee has a mandate; e.g until end of September. But we > can always "fire" the chairmen at any point if we like to. > > Voting period: 20070506 UTC 12:00 until 20070508 UTC 11:59 > ---- > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From buildsys at fedoraproject.org Sun May 6 03:21:43 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 5 May 2007 23:21:43 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-05 Message-ID: <20070506032143.D3F26152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 11 NEW perl-Algorithm-Diff-1.1902-2.el5 NEW perl-Module-Build-0.2807-1.el5 NEW perl-Test-Base-0.53-1.el5 NEW perl-Text-Diff-0.35-3.el5 NEW perl-YAML-0.62-3.el5 php-pear-MDB2-2.4.1-1.el5 php-pear-MDB2-Driver-mysql-1.4.1-1.el5 NEW php-pear-Net-UserAgent-Detect-2.3.0-1.el5 NEW php-pear-Pager-2.4.3-1.el5 NEW php-pear-Payment-Process-0.6.5-1.el5 NEW translate-toolkit-0.10.1-1.el5 Packages built and released for Fedora EPEL 4: 1 NEW cacti-0.8.6j-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun May 6 20:43:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 6 May 2007 16:43:07 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-06 Message-ID: <20070506204307.63CB8152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 15 chrpath-0.13-1.1.el5.1 cmucl-19d-3.el5.1 dclib-0.3.8-1.el5.1 dnsmasq-2.38-1.el5.1 gnustep-make-1.12.0-5.el5.1 libcdaudio-0.99.12p2-8.el5.1 libFoundation-1.1.3-10.el5.1 lzo-2.02-2.el5.1 mock-0.6.8-4.el5.1 mod_auth_shadow-2.2-4.el5.1 naim-0.11.8.3-1.el5.1 nethack-3.4.3-12.el5.1 NEW perl-Net-IPv4Addr-0.10-2.el5 : Perl extension for manipulating IPv4 addresses php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.el5 NEW php-pear-HTML-QuickForm-ElementGrid-0.1.0-1.el5 : Meta-element which holds any other element in a grid Packages built and released for Fedora EPEL 4: 1 NEW perl-Net-IPv4Addr-0.10-2.el4 : Perl extension for manipulating IPv4 addresses Changes in Fedora EPEL 5: chrpath-0.13-1.1.el5.1 ---------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final cmucl-19d-3.el5.1 ----------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final dclib-0.3.8-1.el5.1 ------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final dnsmasq-2.38-1.el5.1 -------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final gnustep-make-1.12.0-5.el5.1 --------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final libcdaudio-0.99.12p2-8.el5.1 ---------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final libFoundation-1.1.3-10.el5.1 ---------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final lzo-2.02-2.el5.1 ---------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final mock-0.6.8-4.el5.1 ------------------ * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final mod_auth_shadow-2.2-4.el5.1 --------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final naim-0.11.8.3-1.el5.1 --------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final nethack-3.4.3-12.el5.1 ---------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final perl-Net-IPv4Addr-0.10-2.el5 ---------------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-2 - Add missing build dependencies - Fix License * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-1 - Initial build php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.el5 ---------------------------------------------------- * Sun May 06 2007 Christopher Stone 1.0.0-0.5.RC7 - Require new HTML_QuickForm_ElementGrid package php-pear-HTML-QuickForm-ElementGrid-0.1.0-1.el5 ----------------------------------------------- * Sun Jan 14 2007 Christopher Stone 0.1.0-1 - Initial Fedora release Changes in Fedora EPEL 4: perl-Net-IPv4Addr-0.10-2.el4 ---------------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-2 - Add missing build dependencies - Fix License * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-1 - Initial build For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Axel.Thimm at ATrpms.net Mon May 7 08:31:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 May 2007 10:31:05 +0200 Subject: proposed vote for the Steering Committee members: Elect a chairmen In-Reply-To: <463C6DCB.80805@leemhuis.info> References: <463C6DCB.80805@leemhuis.info> Message-ID: <20070507083105.GD7810@neu.nirvana> On Sat, May 05, 2007 at 01:43:07PM +0200, Thorsten Leemhuis wrote: > As discussed and decided in recent EPEL Steering Committee meeting we > want to elect a chairmen for the EPEL Steering Committee. It was further > agree upon to use a wiki-vote for the actual election. What happened to defining what this position is about? Some suggestions included strong veto powers and secret agendaing. W/o defining the position's role anything will be interpreted into it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon May 7 08:56:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 May 2007 10:56:20 +0200 Subject: proposed vote for the Steering Committee members: Elect a chairmen In-Reply-To: <20070507083105.GD7810@neu.nirvana> References: <463C6DCB.80805@leemhuis.info> <20070507083105.GD7810@neu.nirvana> Message-ID: <463EE9B4.8070505@leemhuis.info> On 07.05.2007 10:31, Axel Thimm wrote: > On Sat, May 05, 2007 at 01:43:07PM +0200, Thorsten Leemhuis wrote: >> As discussed and decided in recent EPEL Steering Committee meeting we >> want to elect a chairmen for the EPEL Steering Committee. It was further >> agree upon to use a wiki-vote for the actual election. > What happened to defining what this position is about? Some > suggestions included strong veto powers and secret agendaing. W/o > defining the position's role anything will be interpreted into it. Nobody wants veto powers for the chairmen afaics. If someone (chairmen or not) really doesn't like something and would like to veto it then I'd say he should try to convince a higher Committee (FESCo in this case) to revisit the issue. Yes, the chairmen afaics will handle the schedule and coordinate the meetings as someone has to do that. But "someone" did that until now, too -- just now we have some one that is *responsible* that it gets done afaics. Apart from this we simply look how it evolves and define or undefine the job as needed. And, as I said, the Steering Committee can simply "fire" the chair at any time. CU thl From Axel.Thimm at ATrpms.net Mon May 7 08:57:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 May 2007 10:57:29 +0200 Subject: Stepping down from epel, request for self-nominations for successor Message-ID: <20070507085729.GE7810@neu.nirvana> I'm stepping down from EPEL's Steering Committee. As a replacement I recommend one of the following top five packagers in EPEL: steve at silug.org matthias at rpmforge.net rdieter at math.unl.edu orion at cora.nwra.com chris.stone at gmail.com EPEL's Steering Committee has a bad balance between deciders and doers, therefore I suggest to try to get more packaging folks into the game. Maybe that would bring back some things back to balance. The reasons for stepping down are the following: o Personal conflicts with Thorsten Leemhuis. Not much needs to be explained about this, whoever followed a couple of discussions will understand that Thorsten and I are not working well together. Many of the following issues are about where Thorsten is steering EPEL to. o Disapproving EPEL's course I cannot stand for EPEL anymore, not within the project and even more not representing it to the outside. Since people outside EPEL think of me as a bridge between 3rd parties and EPEL I get the load of requests that I by now know I cannot push through into EPEL. o Conflict of interests between EPEL and ATrpms (or successor) Given that I identify myself as primarily a non-EPEL third party contributor (ATrpms), and that cooperation requests like the repotag issue bounced off that ugly on EPEL, I can't fight myself, just as I don't want to fight other established third party repos and RHEL clones. The repotag aftermath alone costed me far too much manpower and things are still in need of further work. o Conflict of interests between EPEL and FPC As the single overlap member between EPEL and FPC I was considered to mediate between the two groups, but I was found myself more often in the position of having to defend FPC from Thorsten's passing on unpleasant EPEL matters to the FPC. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon May 7 09:56:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 May 2007 11:56:50 +0200 Subject: Stepping down from epel, request for self-nominations for successor In-Reply-To: <20070507085729.GE7810@neu.nirvana> References: <20070507085729.GE7810@neu.nirvana> Message-ID: <463EF7E2.6080409@leemhuis.info> On 07.05.2007 10:57, Axel Thimm wrote: > I'm stepping down from EPEL's Steering Committee. It's sad to see you leave. I really wanted you as part of the Steering Committee and as part of EPEL. > As a replacement I > recommend one of the following top five packagers in EPEL: > > steve at silug.org > matthias at rpmforge.net > rdieter at math.unl.edu > orion at cora.nwra.com > chris.stone at gmail.com I'd suggest we discuss this in this weeks meeting then. Can those from the above list please drop me a line (in private, IRC, on the list, whatever) if they are willing to become part of the Steering Committee? CU thl From buildsys at fedoraproject.org Tue May 8 12:12:01 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 8 May 2007 08:12:01 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-08 Message-ID: <20070508121201.61A66152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 33 NEW bcfg2-0.9.3-1.el5 : Configuration management system bitlbee-1.0.3-6.el5 NEW cups-pdf-2.4.6-1.el5 : Extension for creating pdf-Files with CUPS duplicity-0.4.2-7.el5 eggdrop-1.6.18-8.el5 fakechroot-2.5-12.el5.1 fakeroot-1.6.4-15.el5.1 libopm-0.1-4.20050731cvs.el5 librsync-0.9.7-10.el5 mimedefang-2.62-2.el5 moin-1.5.7-2.el5 nas-1.8b-1.el5.1 openvpn-2.1-0.17.rc2.el5.1 p7zip-4.44-2.el5.1 perl-Module-Build-0.2807-2.el5 perl-Net-LibIDN-0.09-3.el5 perl-Readonly-XS-1.04-7.el5.1 NEW perl-Test-Portability-Files-0.05-3.el5 : Check file names portability perl-Text-CharWidth-0.04-2.el5.1 NEW perl-Text-Template-1.44-4.el5 : Expand template text with embedded Perl perl-Unix-Syslog-0.100-9.el5.1 php-idn-1.2-2.el5 NEW php-pear-Structures-DataGrid-0.8.3-1.el5 : Tabular structure for converting data NEW php-pear-Structures-DataGrid-DataSource-Array-0.1.2-1.el5 : DataSource driver using arrays NEW php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.el5 : DataSource driver using PEAR::DB_DataObject pork-0.99.8.1-6.el5.1 python-psycopg2-2.0.5.1-3.el5.1 python-ruledispatch-0.5a0-0.4.svnr2115.el5.1 tcpick-0.2.1-12.el5 xprobe2-0.3-8.el5.1 yaz-2.1.54-1.el5.1 zabbix-1.1.7-1.el5.1 zziplib-0.13.49-1.el5.1 Packages built and released for Fedora EPEL 4: 13 NEW bcfg2-0.9.3-1.el4 : Configuration management system bitlbee-1.0.3-6.el4 NEW cups-pdf-2.4.6-2.el4 : Extension for creating pdf-Files with CUPS duplicity-0.4.2-7.el4 eggdrop-1.6.18-8.el4 NEW lcms-1.15-1.el4 : Color Management System. libopm-0.1-4.20050731cvs.el4 librsync-0.9.7-10.el4 NEW mimedefang-2.62-2.el4 : E-Mail filtering framework using Sendmail's Milter interface moin-1.5.7-2.el4 perl-Net-LibIDN-0.09-3.el4 NEW perl-Text-Template-1.44-4.el4 : Expand template text with embedded Perl tcpick-0.2.1-12.el4 Changes in Fedora EPEL 5: bcfg2-0.9.3-1.el5 ----------------- * Mon Apr 30 2007 Jeffrey C. Ollie - 0.9.3-1 - Update to 0.9.3 bitlbee-1.0.3-6.el5 ------------------- * Mon May 07 2007 Robert Scheck 1.0.3-6 - Rebuilt cups-pdf-2.4.6-1.el5 -------------------- * Sun May 06 2007 Remi Collet 2.4.6-1 - update to 2.4.6 * Sun Apr 08 2007 Remi Collet 2.4.5-1 - update to 2.4.5 duplicity-0.4.2-7.el5 --------------------- * Mon May 07 2007 Robert Scheck 0.4.2-7 - Rebuild eggdrop-1.6.18-8.el5 -------------------- * Mon May 07 2007 Robert Scheck 1.6.18-8 - Rebuild fakechroot-2.5-12.el5.1 ----------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final fakeroot-1.6.4-15.el5.1 ----------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final libopm-0.1-4.20050731cvs.el5 ---------------------------- * Mon May 07 2007 Robert Scheck 0.1-4.20050731cvs - Rebuild librsync-0.9.7-10.el5 --------------------- * Mon May 07 2007 Robert Scheck 0.9.7-10 - rebuilt mimedefang-2.62-2.el5 --------------------- * Mon May 07 2007 Robert Scheck 2.62-2 - Changed sendmail build requirement slightly (#237157) * Mon Apr 16 2007 Robert Scheck 2.62-1 - Upgrade to 2.62 moin-1.5.7-2.el5 ---------------- * Mon May 07 2007 Matthias Saou 1.5.7-2 - Include security fixes from the Debian package (Jonas Smedegaard). - FIX_use_ACL_in_include_directive (Alexander Schremmer). - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). - CVE-2007-0857. nas-1.8b-1.el5.1 ---------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final openvpn-2.1-0.17.rc2.el5.1 -------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final p7zip-4.44-2.el5.1 ------------------ * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final perl-Module-Build-0.2807-2.el5 ------------------------------ * Mon May 07 2007 Steven Pritchard 0.2807-2 - Drop explicit dependency on Pod::Readme. perl-Net-LibIDN-0.09-3.el5 -------------------------- * Mon May 07 2007 Robert Scheck 0.09-3 - Rebuild * Thu Apr 26 2007 Robert Scheck 0.09-2 - Added build requirement to perl(ExtUtils::MakeMaker) perl-Readonly-XS-1.04-7.el5.1 ----------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final perl-Test-Portability-Files-0.05-3.el5 -------------------------------------- * Sat Sep 16 2006 Steven Pritchard 0.05-3 - Fix find option order. perl-Text-CharWidth-0.04-2.el5.1 -------------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final perl-Text-Template-1.44-4.el5 ----------------------------- * Thu Sep 07 2006 Jose Pedro Oliveira - 1.44-4 - Rebuild for FC6. perl-Unix-Syslog-0.100-9.el5.1 ------------------------------ * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final * Mon Apr 16 2007 Steven Pritchard 0.100-9 - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. php-idn-1.2-2.el5 ----------------- * Mon May 07 2007 Robert Scheck 1.2-2 - Rebuild php-pear-Structures-DataGrid-0.8.3-1.el5 ---------------------------------------- * Mon Apr 30 2007 Christopher Stone 0.8.3-1 - Upstream sync php-pear-Structures-DataGrid-DataSource-Array-0.1.2-1.el5 --------------------------------------------------------- * Wed Jan 24 2007 Christopher Stone 0.1.2-1 - Upstream sync php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.el5 -------------------------------------------------------------- * Mon May 07 2007 Christopher Stone 0.1.2-1 - Upstream sync pork-0.99.8.1-6.el5.1 --------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final python-psycopg2-2.0.5.1-3.el5.1 ------------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final python-ruledispatch-0.5a0-0.4.svnr2115.el5.1 -------------------------------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final tcpick-0.2.1-12.el5 ------------------- * Mon May 07 2007 Robert Scheck 0.2.1-12 - Rebuilt xprobe2-0.3-8.el5.1 ------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final yaz-2.1.54-1.el5.1 ------------------ * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final zabbix-1.1.7-1.el5.1 -------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final zziplib-0.13.49-1.el5.1 ----------------------- * Sun May 06 2007 Thorsten Leemhuis - rebuilt for RHEL5 final Changes in Fedora EPEL 4: bcfg2-0.9.3-1.el4 ----------------- * Mon Apr 30 2007 Jeffrey C. Ollie - 0.9.3-1 - Update to 0.9.3 bitlbee-1.0.3-6.el4 ------------------- * Mon May 07 2007 Robert Scheck 1.0.3-6 - Rebuilt cups-pdf-2.4.6-2.el4 -------------------- * Sun May 06 2007 Remi Collet 2.4.6-2 - spec changes for RHEL 4 and Fedora Core 3 and 4 (no selinux) * Sun May 06 2007 Remi Collet 2.4.6-1 - update to 2.4.6 * Sun Apr 08 2007 Remi Collet 2.4.5-1 - update to 2.4.5 duplicity-0.4.2-7.el4 --------------------- * Mon May 07 2007 Robert Scheck 0.4.2-7 - Rebuild eggdrop-1.6.18-8.el4 -------------------- * Mon May 07 2007 Robert Scheck 1.6.18-8 - Rebuild lcms-1.15-1.el4 --------------- * Thu Jan 19 2006 Andreas Bierfert 1.15-1 - verion upgrade libopm-0.1-4.20050731cvs.el4 ---------------------------- * Mon May 07 2007 Robert Scheck 0.1-4.20050731cvs - Rebuild librsync-0.9.7-10.el4 --------------------- * Mon May 07 2007 Robert Scheck 0.9.7-10 - rebuilt mimedefang-2.62-2.el4 --------------------- * Mon May 07 2007 Robert Scheck 2.62-2 - Changed sendmail build requirement slightly (#237157) * Mon Apr 16 2007 Robert Scheck 2.62-1 - Upgrade to 2.62 moin-1.5.7-2.el4 ---------------- * Mon May 07 2007 Matthias Saou 1.5.7-2 - Include security fixes from the Debian package (Jonas Smedegaard). - FIX_use_ACL_in_include_directive (Alexander Schremmer). - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). - CVE-2007-0857. perl-Net-LibIDN-0.09-3.el4 -------------------------- * Mon May 07 2007 Robert Scheck 0.09-3 - Rebuild * Thu Apr 26 2007 Robert Scheck 0.09-2 - Added build requirement to perl(ExtUtils::MakeMaker) perl-Text-Template-1.44-4.el4 ----------------------------- * Thu Sep 07 2006 Jose Pedro Oliveira - 1.44-4 - Rebuild for FC6. tcpick-0.2.1-12.el4 ------------------- * Mon May 07 2007 Robert Scheck 0.2.1-12 - Rebuilt For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Wed May 9 18:53:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 May 2007 20:53:10 +0200 Subject: volunteer searched: get mock configs for EPEL into the mock package Message-ID: <46421896.1020906@leemhuis.info> Hi, mock ships config files for EPEL4 but none for EPEL5 afaics. Is anyone willing to prepare and test EPEL5 config files and submitting them via bugzilla to the mock maintainer for inclusion? CU thl From wolfy at nobugconsulting.ro Wed May 9 20:20:38 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 09 May 2007 23:20:38 +0300 Subject: volunteer searched: get mock configs for EPEL into the mock package In-Reply-To: <46421896.1020906@leemhuis.info> References: <46421896.1020906@leemhuis.info> Message-ID: <46422D16.7060204@nobugconsulting.ro> On 05/09/2007 09:53 PM, Thorsten Leemhuis wrote: > Hi, > > mock ships config files for EPEL4 but none for EPEL5 afaics. Is anyone > willing to prepare and test EPEL5 config files and submitting them via > bugzilla to the mock maintainer for inclusion? > > count on me for that, I already have used mock to locally rebuild ssmtp before submitting to EPEL-5. any specific procedure to be applied or posting the centos-5.cfg is enough ? From fedora at leemhuis.info Thu May 10 04:52:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 May 2007 06:52:37 +0200 Subject: volunteer searched: get mock configs for EPEL into the mock package In-Reply-To: <46422D16.7060204@nobugconsulting.ro> References: <46421896.1020906@leemhuis.info> <46422D16.7060204@nobugconsulting.ro> Message-ID: <4642A515.6050401@leemhuis.info> On 09.05.2007 22:20, Manuel Wolfshant wrote: > On 05/09/2007 09:53 PM, Thorsten Leemhuis wrote: >> mock ships config files for EPEL4 but none for EPEL5 afaics. Is anyone >> willing to prepare and test EPEL5 config files and submitting them via >> bugzilla to the mock maintainer for inclusion? > count on me for that, thx > I already have used mock to locally rebuild ssmtp > before submitting to EPEL-5. > any specific procedure to be applied or posting the centos-5.cfg is enough ? Well, the config should probably follow the scheme the existing EPEL-4 config file from current mock uses (find it attached). If you have one open a bug against mock and tell him that we would be very glad if that file could be added quickly in all major mock branches; if the maintainer doesn't react within a few days please let me know. CU thl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-4-ppc-epel.cfg URL: From buildsys at fedoraproject.org Thu May 10 11:22:01 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 10 May 2007 07:22:01 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-10 Message-ID: <20070510112201.6C884152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW boolstuff-0.1.11-1.el5 : Disjunctive Normal Form boolean expression library php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.el5 php-pear-Net-Socket-1.0.8-1.el5 NEW pmount-0.9.13-1.el5 : Enable normal user mount NEW python-decoratortools-1.4-2.el5 : Use class and function decorators -- even in Python 2.3 Packages built and released for Fedora EPEL 4: 1 NEW boolstuff-0.1.11-1.el4 : Disjunctive Normal Form boolean expression library Changes in Fedora EPEL 5: boolstuff-0.1.11-1.el5 ---------------------- * Sun May 06 2007 Patrice Dumas 0.1.11-1 - update to 0.1.11 - use a directory for in-source docs php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.el5 ----------------------------------------------- * Tue May 08 2007 Christohper Stone 0.1.1-1 - Upstream sync php-pear-Net-Socket-1.0.8-1.el5 ------------------------------- * Tue May 08 2007 Remi Collet 1.0.8-1 - update to 1.0.8 pmount-0.9.13-1.el5 ------------------- * Sun Sep 24 2006 Patrice Dumas 0.9.13-1 - initial packaging python-decoratortools-1.4-2.el5 ------------------------------- * Tue May 08 2007 Luke Macken - 1.4-2 - Own the peak namespace, for now. * Thu May 03 2007 Luke Macken - 1.4-1 - Initial creation Changes in Fedora EPEL 4: boolstuff-0.1.11-1.el4 ---------------------- * Sun May 06 2007 Patrice Dumas 0.1.11-1 - update to 0.1.11 - use a directory for in-source docs For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 11 01:13:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 10 May 2007 21:13:50 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-10 Message-ID: <20070511011350.37762152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 6 hdf-4.2r1-13.el5 (!) perl-Module-Build-0.2807-2.el5 : INVALID rebuild, not published! NEW php-pear-Structures-DataGrid-DataSource-MDB2-0.1.9-1.el5 : DataSource driver using PEAR::MDB2 and an SQL query NEW php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.el5 : DataSource driver using RSS files NEW php-pear-Structures-DataGrid-Renderer-Pager-0.1.2-1.el5 : Renderer driver using PEAR::Pager NEW python-Coherence-0.2.1-3.el5 : Python framework to participate in digital living networks Packages built and released for Fedora EPEL 4: 1 NEW python-Coherence-0.2.1-3.el4 : Python framework to participate in digital living networks Changes in Fedora EPEL 5: hdf-4.2r1-13.el5 ---------------- * Thu May 10 2007 Orion Poplawski 4.2r1-13 - Remove netcdf-devel requires. (bug #239631) * Fri Apr 20 2007 Orion Poplawski 4.2r1-12 - Use 4.2r1-hrepack-p4.tar.gz for hrepack patch - Remove configure patch applied upstream - Use --disable-production configure flag to avoid stripping -g compile flag - Add patch to fix open file test when run under mock perl-Module-Build-0.2807-2.el5 ------------------------------ * Mon May 07 2007 Steven Pritchard 0.2807-2 - Drop explicit dependency on Pod::Readme. php-pear-Structures-DataGrid-DataSource-MDB2-0.1.9-1.el5 -------------------------------------------------------- * Mon Apr 30 2007 Christopher Stone 0.1.9-1 - Upstream sync php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.el5 ------------------------------------------------------- * Sun Jan 14 2007 Christopher Stone 0.1.1-1 - Upstream sync - Relicense to BSD php-pear-Structures-DataGrid-Renderer-Pager-0.1.2-1.el5 ------------------------------------------------------- * Sun Jan 14 2007 Christopher Stone 0.1.2-1 - Upstream sync - Relicense under BSD python-Coherence-0.2.1-3.el5 ---------------------------- * Tue May 08 2007 Matthias Saou 0.2.1-3 - Rename Coherence -> python-Coherence to match our python naming guidelines. * Mon May 07 2007 Matthias Saou 0.2.1-2 - Rename coherence -> Coherence to match upstream and our naming guidelines. - Obsolete coherence < 0.2.1-2 but don't provide it since elisa's requirement has been updated to match the name change and nothing else requires it. * Fri Apr 20 2007 Matthias Saou 0.2.1-1 - Update to 0.2.1. Changes in Fedora EPEL 4: python-Coherence-0.2.1-3.el4 ---------------------------- * Tue May 08 2007 Matthias Saou 0.2.1-3 - Rename Coherence -> python-Coherence to match our python naming guidelines. * Mon May 07 2007 Matthias Saou 0.2.1-2 - Rename coherence -> Coherence to match upstream and our naming guidelines. - Obsolete coherence < 0.2.1-2 but don't provide it since elisa's requirement has been updated to match the name change and nothing else requires it. * Fri Apr 20 2007 Matthias Saou 0.2.1-1 - Update to 0.2.1. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lists at timj.co.uk Fri May 11 12:47:13 2007 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 11 May 2007 13:47:13 +0100 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: References: <4634A1A8.7070903@timj.co.uk> Message-ID: <464465D1.6040501@timj.co.uk> Rex Dieter wrote: > Tim Jackson wrote: --------------------------------------------------------------- >> Repository Community Collaboration Statement >> --------------------------------------------------------------------- > > +1000000! Fantastically awesome, imho. Thanks for the support Rex. But is there really nobody else who is interested in this or has any comments? Either way? From either EPEL or other repos? I won't be offended if everyone thinks it's a waste of time and energy, but I was hoping that it might offer a positive way forward and any constructive comments are welcome. Tim From pertusus at free.fr Fri May 11 13:45:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 May 2007 15:45:11 +0200 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <464465D1.6040501@timj.co.uk> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> Message-ID: <20070511134511.GE4791@free.fr> On Fri, May 11, 2007 at 01:47:13PM +0100, Tim Jackson wrote: > > Thanks for the support Rex. But is there really nobody else who is > interested in this or has any comments? Either way? From either EPEL or > other repos? I won't be offended if everyone thinks it's a waste of time > and energy, but I was hoping that it might offer a positive way forward > and any constructive comments are welcome. I am not sure that it counts a lot, but I agree that this is a very good idea. It seems to me that the signatories should also give some information about how to search whether a package exists, by giving the address of the rpms, srpms ftp sites, informations about where the version control system is when such a thing exists and also provides a way to contact the project, and, when possibile the address of the most relevant mailing list and also maybe the bugzilla for packaging bugs if it exists. And any other information I would have forgotten. I don't think that agreeing to the proposal should be seen as binding for all the members of the project, but more what is the general consent in the project. What I want to say here is that if a contributor dislikes the other repos and don't want to cooperate with them we shouldn't force him but still try collectively to work with other repos (and try to convince the ones who don't want to cooperate). -- Pat From Michael_E_Brown at dell.com Fri May 11 17:32:52 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 11 May 2007 12:32:52 -0500 Subject: volunteer searched: get mock configs for EPEL into the mock package In-Reply-To: <4642A515.6050401@leemhuis.info> References: <46421896.1020906@leemhuis.info> <46422D16.7060204@nobugconsulting.ro> <4642A515.6050401@leemhuis.info> Message-ID: <20070511173252.GA13627@humbolt.us.dell.com> On Thu, May 10, 2007 at 06:52:37AM +0200, Thorsten Leemhuis wrote: > On 09.05.2007 22:20, Manuel Wolfshant wrote: > > On 05/09/2007 09:53 PM, Thorsten Leemhuis wrote: > >> mock ships config files for EPEL4 but none for EPEL5 afaics. Is anyone > >> willing to prepare and test EPEL5 config files and submitting them via > >> bugzilla to the mock maintainer for inclusion? > > count on me for that, > > thx > > > I already have used mock to locally rebuild ssmtp > > before submitting to EPEL-5. > > any specific procedure to be applied or posting the centos-5.cfg is enough ? > > Well, the config should probably follow the scheme the existing EPEL-4 > config file from current mock uses (find it attached). > > If you have one open a bug against mock and tell him that we would be > very glad if that file could be added quickly in all major mock > branches; if the maintainer doesn't react within a few days please let > me know. Clark Williams and I are the mock maintainers. I havent seen a bug on this yet, but can put this in. Two things: -- I am at RH Summit in San Diego right now and wont be able to get to this until I get back -- We have a permissions problem on the git repository where I cannot commit and I'm waiting for resolution from the fedora guys on that. (They appear to be really busy right now with F7) -- Michael > > CU > thl > #!/usr/bin/python -tt > import os > config_opts['root'] = 'epel-4-ppc' > config_opts['target_arch'] = 'ppc' > > config_opts['yum.conf'] = """ > [main] > cachdir=/var/cache/yum > debuglevel=1 > logfile=/var/log/yum.log > reposdir=/dev/null > retries=20 > obsoletes=1 > gpgcheck=0 > assumeyes=1 > > # repos > > [core] > name=base > mirrorlist=http://mirror.centos.org/?release=4&arch=ppc&repo=os > > [update] > name=updates > mirrorlist=http://mirror.centos.org/?release=4&arch=ppc&repo=updates > > [groups] > name=groups > baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/ppc/ > > [extras] > name=epel > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=ppc > > [local] > name=local > baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ > > """ > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list From wolfy at nobugconsulting.ro Fri May 11 19:28:17 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 11 May 2007 22:28:17 +0300 Subject: volunteer searched: get mock configs for EPEL into the mock package In-Reply-To: <20070511173252.GA13627@humbolt.us.dell.com> References: <46421896.1020906@leemhuis.info> <46422D16.7060204@nobugconsulting.ro> <4642A515.6050401@leemhuis.info> <20070511173252.GA13627@humbolt.us.dell.com> Message-ID: <4644C3D1.2090606@nobugconsulting.ro> On 05/11/2007 08:32 PM, Michael E Brown wrote: > On Thu, May 10, 2007 at 06:52:37AM +0200, Thorsten Leemhuis wrote: > >> On 09.05.2007 22:20, Manuel Wolfshant wrote: >> >>> On 05/09/2007 09:53 PM, Thorsten Leemhuis wrote: >>> >>>> mock ships config files for EPEL4 but none for EPEL5 afaics. Is anyone >>>> willing to prepare and test EPEL5 config files and submitting them via >>>> bugzilla to the mock maintainer for inclusion? >>>> >>> count on me for that, >>> >> thx >> >> >>> I already have used mock to locally rebuild ssmtp >>> before submitting to EPEL-5. >>> any specific procedure to be applied or posting the centos-5.cfg is enough ? >>> >> Well, the config should probably follow the scheme the existing EPEL-4 >> config file from current mock uses (find it attached). >> >> If you have one open a bug against mock and tell him that we would be >> very glad if that file could be added quickly in all major mock >> branches; if the maintainer doesn't react within a few days please let >> me know. >> > > Clark Williams and I are the mock maintainers. I havent seen a bug on > this yet, but can put this in. > > Two things: > -- I am at RH Summit in San Diego right now and wont be able to get to > this until I get back > -- We have a permissions problem on the git repository where I cannot > commit and I'm waiting for resolution from the fedora guys on that. > (They appear to be really busy right now with F7) > The computer I perform tests on is offline too, so I'll proceed with my promise next week. Manuel From fedora at leemhuis.info Sat May 12 11:18:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 May 2007 13:18:36 +0200 Subject: Log from EPEL SIG meeting 20070509 Message-ID: <4645A28C.9000903@leemhuis.info> Hi! Find below the full log of this weeks EPEL meeting. I plan to send it separately of the summary in the future and will try to send it immediately after the meeting so everyone who wants knows what up right in time. I'll of course will continue to write summaries, but that often takes some days, as real life comes in the my way often -- especially as I leave the keyboards often right after the meeting. Hope that acceptable for everyone. CU knurd 00:02 < nirik> | epel meeting? 00:03 * | knurd will be around soon 00:03 < stahnma> | here...but on phone 00:03 * | knurd on the telphone 00:03 * | dgilmore is here 00:03 * | knurd got gid of the phone now 00:03 < nirik> | ok. 00:03 < nirik> | pesky phones. 00:03 --- | knurd has changed the topic to: EPEL meeting -- init phase 00:03 < knurd> | hi everyone; 00:03 < knurd> | who's around? 00:04 * | dgilmore 00:04 <-- | warren has quit (Remote closed the connection) 00:04 <-- | jeremy has quit (Remote closed the connection) 00:04 * | stahnma 00:04 < knurd> | Sorry, I missed again to post the meeting topics beforehand 00:04 < knurd> | I plan to update the schedule in the wiki later today 00:04 < knurd> | and create a topic list there 00:04 < knurd> | so it's a bit easier to handle 00:04 * | nirik is here 00:04 < dgilmore> | brb need to add ram to machine 00:05 < knurd> | quaid, won't be around today 00:05 < knurd> | mmcgrath is on the summit and will likely miss the meeting as well 00:05 < knurd> | so that makes only four people today 00:06 < knurd> | from the steering committee 00:06 * | mmcgrath actually lurks a bit for the buildsys outage. 00:06 < knurd> | so, let's start 00:06 --- | knurd has changed the topic to: EPEL Meeting -- chairmen 00:07 < knurd> | well, seems I've lost or won -- depending on how people look at it 00:07 < knurd> | I'll put that info in the wiki somewhere 00:08 < stahnma> | brb 00:08 < stahnma> | cluster work 00:08 < knurd> | do we want to keep the "Steering Committee Chairmen" section on http://fedoraproject.org/wiki/EPEL/SteeringCommittee ? 00:08 --> | warren (Unknown) has joined #fedora-meeting 00:09 < knurd> | anyone? 00:09 < nirik> | knurd: sure. 00:09 < nirik> | I think you have basically been doing those things anyhow... ;) 00:09 < knurd> | k; I'll leave it there then 00:09 < knurd> | we can always revisit that later if we want to 00:10 < knurd> | moving on 00:10 --- | knurd has changed the topic to: EPEL meeting -- thimm leaving 00:10 --- | knurd has changed the topic to: EPEL meeting -- thimm leaving -- vacant seat in the Steering Committee 00:10 --> | aalamC (A S Alamwala community) has joined #fedora-meeting 00:11 * | nirik is sorry to see him leave, even tho he didn't always agree with him. 00:11 < knurd> | well, I really would have liked it if thimm would be around, but leaving is his decision 00:11 < nirik> | did any of the suggested folks reply to you about stepping up knurd ? 00:11 <-- | Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: giallu 00:11 < knurd> | nirik, nope, none of them 00:12 < nirik> | might ask on the list? anyone with epel packages/interest that wants to help and can make the meetings? 00:12 < knurd> | maybe 00:12 < knurd> | any suggestion from here? 00:12 < knurd> | I'm fine with silug; he has quite a lot of packages in EPEL afaics 00:12 < knurd> | rdieter is in Board, FESCo and FPC already 00:13 < knurd> | nirik, maybe it's better to ask those thimm proposed in a private mail? 00:13 < nirik> | oh yeah... did you mail them? or just wait to hear after thimm's email? 00:14 < knurd> | I just waited 00:14 < knurd> | I'll mail them directly, that should help 00:14 < knurd> | anyone else we'd like to see in the steering committee? 00:14 < knurd> | otherwise i'll mail those five thimm suggested 00:14 < knurd> | and then we'll choose one in the next meeting 00:15 < nirik> | that sounds like a good way to start. 00:15 < knurd> | k 00:15 < stahnma> | ok back 00:15 < knurd> | anything else regarding this topic? 00:15 --> | giallu (Gianluca Sforna) has joined #fedora-meeting 00:16 * | knurd moves on 00:16 --- | knurd has changed the topic to: EPEL Meeting -- mass rebuild for RHEL5 00:16 < knurd> | done afaics 00:16 * | nirik saw that knurd did some checkins/builds sunday 00:16 < nirik> | excellent. 00:16 < knurd> | I rebuild all arch pacakges that were not rebuild yet 00:16 < knurd> | I didn't touch the noarch ones 00:16 < knurd> | that should suffice afaics 00:16 < nirik> | yeah, I think so. 00:16 < stahnma> | sounds good to me 00:16 <-- | Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: giallu 00:16 < knurd> | k 00:17 --> | Netsplit Over - Joins: giallu 00:17 < knurd> | I'll send a "if you waited for a start signal to build you packages for epel then this is it" mail to fedora-maintainers over the next few days 00:17 < stahnma> | great 00:17 < knurd> | as discussed in earlier meetings 00:17 < nirik> | cool. 00:17 < stahnma> | I got responses like that from a few people I asked about packages 00:18 * | stahnma is wanting most perl modules badly 00:18 < knurd> | but that needs one thing: 00:18 --- | knurd has changed the topic to: EPEL Meeting -- shortcut for branching -- dgilmore? 00:18 < nirik> | yeah, I got a email back from jpo (who maintains a ton of perl modules) like that. 00:18 < knurd> | dgilmore, your around? 00:18 < stahnma> | me too, same guy :) 00:18 < knurd> | nirik, jpo added himself to the SIG afaics 00:18 < knurd> | will he build his packages for EPEL? 00:18 < nirik> | yeah, he is waiting for official announce, rebuild with final 5 done, and perl-Module-Build 00:18 < stahnma> | he said once it was officially opne 00:18 < stahnma> | yeah, what nirik said 00:18 < knurd> | k 00:19 < knurd> | sounds great 00:19 < nirik> | he has around 150 packages. 00:19 < knurd> | but people like him will branch a lot of packages 00:19 < knurd> | they need a shortcut 00:19 < knurd> | dgilmore has a script afaik 00:19 < nirik> | yeah. 00:19 < knurd> | but I don#t know what informations he needs for that script 00:19 < knurd> | I need them for my "start now" mail 00:19 < stahnma> | hmm 00:19 < stahnma> | maybe username and any packages to exclude 00:20 * | knurd afk for 1 minute 00:20 < stahnma> | otherwise branch all of that owner's pacakges? 00:20 < nirik> | or username and list of packages to branch 00:20 --- | couf_afk is now known as couf 00:21 < knurd> | i thought we use something similar as in the past on the cvssync page 00:21 < knurd> | e.g. 00:22 < knurd> | foo at bar EL-5 foobar baz this that 00:22 < knurd> | foo at bar EL-4 foobar baz 00:22 < knurd> | well, we don#t get much further without dgilmore here 00:22 < knurd> | I'll move on 00:22 < stahnma> | that's fine for me also 00:22 < stahnma> | k 00:22 < knurd> | and try to find a solution with him later 00:22 < nirik> | yeah, he can answer that when people need it. 00:23 --- | knurd has changed the topic to: EPEL Meeting -- repotags/interaction with 3rd party repos 00:23 < knurd> | sorry, I did not find time to look into this further 00:23 < knurd> | I'm still unsure myself what do to about it 00:23 < knurd> | any suggestions? 00:23 < knurd> | anyone willig to drive this task? 00:23 < nirik> | yeah, the problem is that we can't keep discussing it forever. 00:24 < knurd> | or shall we simply put out feed down? 00:24 < nirik> | we decided no repotags. I suppose it can be revistied, but I don't know if there is really any new info... 00:24 < knurd> | feet 00:24 < nirik> | down the road we really need yum to handle showing what repo packages are from 00:24 < nirik> | with conflicts, etc 00:24 < knurd> | nirik, +1 00:25 < nirik> | we could do repotags now to paste over the problem, but I'm not sure how much it really helps. 00:25 < knurd> | well, shall I mention a "if you really want repotags speak now or we will continue without them" in this weeks summary? 00:25 < nirik> | also, there isn't a good way to automagically add them. 00:25 < knurd> | and then see what happens over the week 00:26 < knurd> | and then decide next week 00:26 < knurd> | nirik, exactly; 00:26 < stahnma> | haven't we already had this discussion? 00:26 < knurd> | if we wanted them we would have a hard time to get them approved by the FPC as well 00:26 < knurd> | stahnma, likely :-/ 00:26 < knurd> | that why I'm asking if we really want to put our feet down 00:27 < stahnma> | I mean, we either decided or we didn't 00:27 < nirik> | many times. 00:27 < knurd> | k 00:27 < stahnma> | I would like to see them, but I am not going to say it's the end of the world without them 00:27 < nirik> | you can add a note and see if any of the folks who want them come up with a new compelling argument. 00:27 < knurd> | nirik, k, will do that 00:27 < knurd> | then we can see what happens over the week 00:27 < knurd> | and finally decide next week 00:28 < knurd> | k? 00:28 < nirik> | well, rather I would say we will see if we need to revisit it, I think we already did decide. 00:28 --> | jeremy (Jeremy Katz) has joined #fedora-meeting 00:28 < stahnma> | can we have the "official open" notice until the repo-tag issue is settled? 00:28 < stahnma> | I mean, if it's going to require a rebuild of everything again...that woudl be bad 00:28 < nirik> | I suppose we could just not move forward and wait for yum to handle multi-repo better. So sometime in 2008/2009 we could do something. ;) 00:29 < knurd> | stahnma, no, I'm against that 00:29 < knurd> | stahnma, even if we decide to do repotags over the next two weeks 00:29 < knurd> | we would need to get them past FPC and FESCo 00:29 < stahnma> | I think we should just move on without tags for now 00:29 < knurd> | that might takes some weeks 00:29 < knurd> | I don't want to wait so long 00:29 < knurd> | stahnma, +1 00:29 < stahnma> | and try to help Yum developers and whatnot 00:29 < knurd> | stahnma, btw, we only open the repo for contributors 00:30 < stahnma> | basically help find really solutions to the problem and not band-aids 00:30 < knurd> | for users it will stay unannouced, but open in a testing stage 00:30 < stahnma> | yes 00:30 < stahnma> | ok 00:30 --- | knurd has changed the topic to: EPEL Meeting -- free discussion around EPEL 00:30 < knurd> | anything else? 00:31 < knurd> | just FYI, I'm going through the wiki currently 00:31 < stahnma> | is anyone concerned about the lack of package for RHEL 4? 00:31 < stahnma> | It's seems like RHEL 5 has many 00:31 < knurd> | a but clean up here and there 00:31 < stahnma> | and RHEL 4 has few 00:31 < nirik> | I suppose we could look at cooperating with the centos folks on their plugin: http://wiki.centos.org/PackageManagement/Yum/Priorities 00:31 < stahnma> | in business, RHEL 5 isn't deployed anywhere yet 00:31 < knurd> | stahnma, well, we have to see how it evolves 00:31 < knurd> | stahnma, seems some contributors only want to do RHEL5 and later 00:31 < nirik> | there are probibly some things that won't work on rhel4, since versions are old, etc. 00:32 < knurd> | nirik, yeah, likely 00:32 < stahnma> | I understand that, but we will have to see what key packages are not there 00:32 < knurd> | I think out main goal is RHEL5 and later 00:32 < nirik> | yeah... 00:32 < knurd> | RHEL4 is a bonus 00:32 < stahnma> | ok 00:32 < knurd> | but most people that have RHEL4 and need extras packages might have a solution already 00:32 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:33 < stahnma> | knurd: many yes. Some organziation are really just staring moves toward RHEL 4 now 00:33 < knurd> | stahnma, well, we can ask people for more effort in the EL4 area 00:33 < knurd> | stahnma, do you want to try? 00:33 < knurd> | I can mention it in my "start now" mail as well 00:33 < stahnma> | try what? 00:33 < stahnma> | either way is ok 00:33 < stahnma> | I just wanted to bring up what I noticed 00:34 < knurd> | stahnma, yeah, I noticed that as well 00:34 < stahnma> | I agree that most RHEL 4 shops will have a solution already 00:34 * | nirik is waiting for an el-4 branch for one of his packages. ;) 00:34 < knurd> | how about waiting what happens after we open it for contrinbutors 00:34 < stahnma> | that's fine 00:34 --> | SmootherFrOgZ (Unknown) has joined #fedora-meeting 00:34 < knurd> | and decide then if we want to encourage it more 00:35 < stahnma> | sounds like a plan to me 00:35 < knurd> | wregarding the wiki 00:35 < knurd> | could one of you guys skimm over it in the next few days? 00:35 < knurd> | I'll do some changes later today 00:35 < stahnma> | I'll read up on it 00:35 < knurd> | but someone should sainity check them 00:35 < knurd> | stahnma, thx 00:35 < knurd> | anything else? 00:36 < stahnma> | Have we defined the QA process? 00:36 < stahnma> | like how we move from testing to production? 00:36 < stahnma> | I know we've discussed it a few times 00:36 < stahnma> | is it documented 00:36 < stahnma> | so I can educate myself on it 00:36 < nirik> | I thought it was on the wiki... 00:37 < knurd> | stahnma, there is something about it on http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates 00:37 < stahnma> | (see that's why I need to read-up on the wiki ;) ) 00:37 < knurd> | in short: 00:37 < knurd> | everything gets into testing first 00:37 < knurd> | and into the proper repo with the next quarterly update 00:37 < knurd> | security updates of course go to the proper repo as well 00:38 < knurd> | how we make that rechnically work remains to be seen 00:38 < knurd> | but it shound't be to hard to realize afaics 00:38 < nirik> | yeah,we need approprate push scripts to do that and/or bodhi. 00:38 < stahnma> | ok 00:38 < stahnma> | I guess bodhi is where I'm a rookie 00:38 < stahnma> | it looks really neat though 00:39 < knurd> | I'm also not familiar with the updates script/bodhi 00:39 < nirik> | yeah, I don't think it's ready to deploy tho 00:39 < stahnma> | ok 00:39 < nirik> | I think the current script dgilmore has been using just is the extras one, so it pushes to the main repo... no testing. 00:39 < knurd> | no yet, but we get closer; but the current updates-syipt might suffice, too 00:40 < knurd> | nirik, we maybe could use some tricks to get a kind of testing repo 00:40 < nirik> | we need to probibly modify that to do testing, and only main repo on quarterly updates and/or if a release manager does a security/major bugfix 00:40 < stahnma> | ok 00:40 < stahnma> | we will also need to update epel-release if we actually start uses testing 00:40 * | nirik added his company mirror to mirror epel... as did several other sites. 00:40 < stahnma> | because right now there is not yum stuff for it 00:40 < knurd> | stahnma, "yum stuff"? 00:40 < nirik> | yeah, we will need to add testing (disabled) 00:41 < stahnma> | .repo files 00:41 < knurd> | ohh, you mean for testing? 00:41 < stahnma> | the URL is for prod 00:41 < nirik> | knurd: yum.repos.d/testing or updates-testing, etc 00:41 < stahnma> | right 00:41 < knurd> | yeah, we need that 00:41 < stahnma> | yeah, my English lacks articulation today 00:41 < knurd> | we need dgilmore or mmcgrath for that probably 00:41 < knurd> | as they are familar with the buildsys and repo stuff 00:41 < nirik> | yeah 00:41 < knurd> | and have the permissions on the right machines 00:42 < knurd> | does anyone want to driver that with those two? 00:42 < knurd> | drive 00:43 < knurd> | well, I'll put it on the schedule 00:43 < nirik> | I can ping them, but I think they just need to be around to do it. 00:43 < knurd> | nirik, sounds like a start 00:43 < nirik> | ok, will drop them an email on it. ;) 00:43 < knurd> | anything else? 00:44 * | knurd will close the meeting in 60 00:44 * | knurd will close the meeting in 30 00:45 * | knurd will close the meeting in 10 00:45 < knurd> | -- MARK -- Meeting end From fedora at leemhuis.info Sat May 12 11:22:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 May 2007 13:22:30 +0200 Subject: EPEL report 2007, week 19 Message-ID: <4645A376.5010102@leemhuis.info> Hi all! FESCo this week finally decided the details how sub-groups like EPEL should report their doings. In short: there should be weekly reports that must be send to fedora-maintainers for public discussion. The reports also get send to the (private) FESCo-list, to make sure FESCo members don't miss the reports in the noise. This EPEL report is the first one that follows this new scheme -- note that I'll send it to epel-devel-list as well (thus three lists in total!), to make sure non-fedora-contributors that might be interested in EPEL are also aware of what happened and are able join the discussions (they can't on fedora-maintainers, as that's a private list open only for contributors). My preferred discussion ground for replies to this reports would be epel-devel-list, as that's open to everyone -- but I assume some discussions in reply to this reports will happen either on both lists, or just on one. You have been warned. (Side note: I hope we find a better solution after the mailing list reorganisation, which got discussed months ago, but was put on hold until we have new hardware in place and F7 out the door). And another note: In the past EPEL had reports that were meeting-centric -- e.g. mainly the summary of the meetings that happen on Wednesday at 17:00 UTC in #fedora-meeting on freenode. The reports in the future will likely be meeting focused with a summary of the meeting as well, but I'll try to integrate some general notes about what happened in EPEL-land over the last week added as well, so non-EPEL contributors can easily follow all the important happenings. Find the report below! CU knurd ---- = Weekly EPEL Summary = Week 19/2007 == Most important happenings == * Axel Thimm left the EPEL SIG and the EPEL Steering Committee; see https://www.redhat.com/archives/epel-devel-list/2007-May/msg00019.html for details. The Steering Committee is looking for a replacement. * the Steering Committee elected knurd as its chairmen; stahnma will act as backup * now that the RHEL5 rebuild is finished knurd will send a "if you waited for a start signal to build your packages for EPEL this is it" mail over the next few days to fedora-maintainers * repotags -- some discussion in the meeting again. It looks like it will we'll continue without repotags (final decision probably in next weeks meeting, after this summary has been posted and discussed). If you want repotags please *speak up now* and *help* to find a technical solution that is not only fine for the EPEL Steering Committee, but also acceptable for the Fedora Packaging Committee and FESCo -- from discussions on list and on IRC it looks like that some members of those groups tend to be against using repotags (see this weeks FESCo meeting for example) or want to see something cooperation statements signed by EPEL and 3rd party repos before they are willing to accept repotags. In other words: it looks like it will be a whole lot of work to go for repotags in EPEL -- some people might be willing to accept repotags if someone does the wor out the details how to realize them in a way that is acceptable for the different Committees. But it seems nobody is in sight to do it. So if you want repotags and are willing to do that work speak up now -- then there is a chance EPEL might get repotags in the near future. == EPEL SIG Meeting == === Attending === >From the Steering Committee: dgilmore (partially), knurd, mmcgrath (partially), nirik, stahnma Other contributors that joined the meeting: rdieter, smooge === Summary === * knurd was elected as chair by the steering committee in a wiki voting over the past week; stahnma will act as a backup / kind of "vice-president". See http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting for details * thimm leaving / vacant seat in the Steering Committee : knurd will mail those people that thimm suggested and ask them if they are willig to become meber of the steering committee. Then we'll decide how to move on. * mass rebuild for RHEL5 -- knurd did rebuild the remaining arch packages over the weekend; issue solved. knurd will send a "if you waited for a start signal to build you packages for epel then this is it" mail to fedora-maintainers over the next few days . knurd and dgilmore will work something out to make branching lots of packages easier. * repotags/interaction with 3rd party repos -- nirik> "we can't keep discussing it forever. " Some discussions to "put our feed down" and go as planed without repotags. See "Most important happenings" for more details * 00:30 and later; some discussions around commitment to EPEL4 stahnma> | is anyone concerned about the lack of package for RHEL 4? It's seems like RHEL 5 has many a but clean up here and there and RHEL 4 has few knurd> | stahnma, well, we have to see how it evolves ; seems some contributors only want to do RHEL5 and later nirik> | there are probibly some things that won't work on rhel4, since versions are old, etc. See full log for all the details * knurd did a some cleanup and additions to the EPEL docs in the wiki and asks people to look over the changes * QA process/testing repo/upload -- we need someone to look into that (bodhi, push scrips) closer. Any volunteers? === Full meeting log === https://www.redhat.com/archives/epel-devel-list/2007-May/msg00031.html == Stats == === EPEL 5 === Number of source packages: 225 Number of binary packages: 373 Packages added over the past week: * boolstuff | Disjunctive Normal Form boolean expression library * php-pear-Structures-DataGrid-DataSource-MDB2 | DataSource driver using PEAR::MDB2 and an SQL query * php-pear-Structures-DataGrid-DataSource-RSS | DataSource driver using RSS files * php-pear-Structures-DataGrid-Renderer-Pager | Renderer driver using PEAR::Pager * pmount | Enable normal user mount * python-Coherence | Python framework to participate in digital living networks * python-decoratortools | Use class and function decorators -- even in Python 2.3 === EPEL 4 === Number of source packages: 158 Number of binary packages: 312 Packages added over the past week: * boolstuff | Disjunctive Normal Form boolean expression library * python-Coherence | Python framework to participate in digital living networks From jwboyer at jdub.homelinux.org Sat May 12 12:45:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 07:45:58 -0500 Subject: EPEL report 2007, week 19 In-Reply-To: <4645A376.5010102@leemhuis.info> References: <4645A376.5010102@leemhuis.info> Message-ID: <1178973958.17555.7.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 13:22 +0200, Thorsten Leemhuis wrote: > > Find the report below! Overall, looks great. A few comments below. > = Weekly EPEL Summary = > > Week 19/2007 > > == Most important happenings == > > * Axel Thimm left the EPEL SIG and the EPEL Steering Committee; see > https://www.redhat.com/archives/epel-devel-list/2007-May/msg00019.html > for details. The Steering Committee is looking for a replacement. Unfortunate. We wish Axel the best. > * the Steering Committee elected knurd as its chairmen; stahnma will > act as backup Could we use Real Names instead of IRC nicks? I know who knurd is but I don't know who stahnma is. > * now that the RHEL5 rebuild is finished knurd will send a "if you > waited for a start signal to build your packages for EPEL this is it" > mail over the next few days to fedora-maintainers > > * repotags -- some discussion in the meeting again. It looks like it > will we'll continue without repotags (final decision probably in next > weeks meeting, after this summary has been posted and discussed). If you > want repotags please *speak up now* and *help* to find a technical > solution that is not only fine for the EPEL Steering Committee, but also > acceptable for the Fedora Packaging Committee and FESCo -- from > discussions on list and on IRC it looks like that some members of those > groups tend to be against using repotags (see this weeks FESCo meeting > for example) or want to see something cooperation statements signed by > EPEL and 3rd party repos before they are willing to accept repotags. Just some clarification. Yes, FESCo overall didn't see a good reason to use repotags. If EPEL chooses to do so, FESCo won't stand in the way. It would be unfortunate, however, if EPEL and FESCo packaging guidelines diverged. josh From fedora at leemhuis.info Sat May 12 13:10:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 May 2007 15:10:54 +0200 Subject: EPEL report 2007, week 19 In-Reply-To: <1178973958.17555.7.camel@vader.jdub.homelinux.org> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> Message-ID: <4645BCDE.2070203@leemhuis.info> Josh Boyer schrieb: > On Sat, 2007-05-12 at 13:22 +0200, Thorsten Leemhuis wrote: >> Find the report below! > Overall, looks great. A few comments below. thx BTW, I put it into the wiki now, too. http://fedoraproject.org/wiki/EPEL/Reports >> * the Steering Committee elected knurd as its chairmen; stahnma will >> act as backup > Could we use Real Names instead of IRC nicks? I know who knurd is but I > don't know who stahnma is. I tried that in the past and it makes stuff harder and time consuming to write in my experience (I have the nicks from the meeting log already and don't have to type them again or look out how peoples names are spelled correctly). So I prefer to use nicks as writing summaries and reports is boring enough already. >> * repotags -- some discussion in the meeting again. It looks like it >> will we'll continue without repotags (final decision probably in next >> weeks meeting, after this summary has been posted and discussed). If you >> want repotags please *speak up now* and *help* to find a technical >> solution that is not only fine for the EPEL Steering Committee, but also >> acceptable for the Fedora Packaging Committee and FESCo -- from >> discussions on list and on IRC it looks like that some members of those >> groups tend to be against using repotags (see this weeks FESCo meeting >> for example) or want to see something cooperation statements signed by >> EPEL and 3rd party repos before they are willing to accept repotags. > Just some clarification. Yes, FESCo overall didn't see a good reason to > use repotags. If EPEL chooses to do so, FESCo won't stand in the way. FYI: I was a bit against repotags in the past, but my position these days after all this discussions is similar. Or, to be more verbose: If someone works out the details on how to realize repotags in Fedora then (depending on how the proposal looks like) I'll likely abstain from a vote or might even support to use repotags, as long as a simple "cp FC-6/foo.spec EL-5/" remains possible. But I don't have the energy to work out the details. Anyone willing to work them out? > It would be unfortunate, however, if EPEL and FESCo packaging guidelines > diverged. That what I want to prevent, too. CU thl From fedora at leemhuis.info Sat May 12 16:18:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 May 2007 18:18:16 +0200 Subject: volunteer searched: get mock configs for EPEL into the mock package In-Reply-To: <20070511173252.GA13627@humbolt.us.dell.com> References: <46421896.1020906@leemhuis.info> <46422D16.7060204@nobugconsulting.ro> <4642A515.6050401@leemhuis.info> <20070511173252.GA13627@humbolt.us.dell.com> Message-ID: <4645E8C8.5060206@leemhuis.info> Michael E Brown schrieb: > On Thu, May 10, 2007 at 06:52:37AM +0200, Thorsten Leemhuis wrote: >> On 09.05.2007 22:20, Manuel Wolfshant wrote: >>> On 05/09/2007 09:53 PM, Thorsten Leemhuis wrote: >>>> mock ships config files for EPEL4 but none for EPEL5 afaics. Is anyone >>>> willing to prepare and test EPEL5 config files and submitting them via >>>> bugzilla to the mock maintainer for inclusion? >>> count on me for that, >>> I already have used mock to locally rebuild ssmtp >>> before submitting to EPEL-5. >>> any specific procedure to be applied or posting the centos-5.cfg is enough ? >> Well, the config should probably follow the scheme the existing EPEL-4 >> config file from current mock uses (find it attached). >> >> If you have one open a bug against mock and tell him that we would be >> very glad if that file could be added quickly in all major mock >> branches; if the maintainer doesn't react within a few days please let >> me know. > Clark Williams and I are the mock maintainers. I havent seen a bug on > this yet, but can put this in. thx for your help. > Two things: > -- I am at RH Summit in San Diego right now and wont be able to get to > this until I get back np > -- We have a permissions problem on the git repository where I cannot > commit and I'm waiting for resolution from the fedora guys on that. > (They appear to be really busy right now with F7) Life is fun :-) Well, it will hopefully get solved soon. Anyway, I got impatient and created mock configs myself. Find them attached. Do they look good? Anyone spotting any stupid typos? I tried the i386 and the x86_64 one and they worked fine afaics. Note: I changed the URL from http://mirror.centos.org in the fedora-4*epel files to http://mirrorlist.centos.org in the new ones, as that's what CentOS uses in CentOS 5. CU thl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-i386-epel.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-ppc-epel.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-x86_64-epel.cfg URL: From mmcgrath at redhat.com Sat May 12 16:55:45 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 12 May 2007 11:55:45 -0500 Subject: From the Summit Message-ID: <4645F191.9030209@redhat.com> The summit is done and I actually heard a few questions about EPEL from some of those attending. Shortly after our Fedora QA session someone approached me regarding the new Red Hat Exchange stuff (rhx.redhat.com). Some ideas included looking into handing packaging of some enterprise apps out in the open by the vendors using our packaging standards. It was interesting and nice to hear that we're getting around and raising eyebrows, I thought I'd pass that along. -Mike From nando at ccrma.Stanford.EDU Sat May 12 19:04:35 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sat, 12 May 2007 12:04:35 -0700 Subject: EPEL report 2007, week 19 In-Reply-To: <4645BCDE.2070203@leemhuis.info> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> Message-ID: <1178996675.12610.14.camel@cmn3.stanford.edu> On Sat, 2007-05-12 at 15:10 +0200, Thorsten Leemhuis wrote: > Josh Boyer schrieb: > > On Sat, 2007-05-12 at 13:22 +0200, Thorsten Leemhuis wrote: > >> Find the report below! > > Overall, looks great. A few comments below. > > thx > > BTW, I put it into the wiki now, too. > http://fedoraproject.org/wiki/EPEL/Reports > > > >> * the Steering Committee elected knurd as its chairmen; stahnma will > >> act as backup > > Could we use Real Names instead of IRC nicks? I know who knurd is but I > > don't know who stahnma is. > > I tried that in the past and it makes stuff harder and time consuming to > write in my experience (I have the nicks from the meeting log already > and don't have to type them again or look out how peoples names are > spelled correctly). So I prefer to use nicks as writing summaries and > reports is boring enough already. > > >> * repotags -- some discussion in the meeting again. It looks like it > >> will we'll continue without repotags (final decision probably in next > >> weeks meeting, after this summary has been posted and discussed). If you > >> want repotags please *speak up now* I do. But maybe you are just asking for "I do"'s from list participants that do not have a third party repo? Rationale for support has been already hashed to death in many threads. > >> and *help* to find a technical > >> solution that is not only fine for the EPEL Steering Committee, but also > >> acceptable for the Fedora Packaging Committee and FESCo -- from > >> discussions on list and on IRC it looks like that some members of those > >> groups tend to be against using repotags (see this weeks FESCo meeting > >> for example) or want to see something cooperation statements signed by > >> EPEL and 3rd party repos before they are willing to accept repotags. > > Just some clarification. Yes, FESCo overall didn't see a good reason to > > use repotags. If EPEL chooses to do so, FESCo won't stand in the way. > > FYI: I was a bit against repotags in the past, but my position these > days after all this discussions is similar. > > Or, to be more verbose: If someone works out the details on how to > realize repotags in Fedora then (depending on how the proposal looks > like) I'll likely abstain from a vote or might even support to use > repotags, as long as a simple "cp FC-6/foo.spec EL-5/" remains possible. > > But I don't have the energy to work out the details. Anyone willing to > work them out? I presume this is internal help? (meaning how to tweak the build system to support them transparently without any impact to the spec files themselves?) > > It would be unfortunate, however, if EPEL and FESCo packaging guidelines > > diverged. > > That what I want to prevent, too. -- Fernando From nando at ccrma.Stanford.EDU Sat May 12 19:08:14 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sat, 12 May 2007 12:08:14 -0700 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <464465D1.6040501@timj.co.uk> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> Message-ID: <1178996894.12610.17.camel@cmn3.stanford.edu> On Fri, 2007-05-11 at 13:47 +0100, Tim Jackson wrote: > Rex Dieter wrote: > > > Tim Jackson wrote: > --------------------------------------------------------------- > >> Repository Community Collaboration Statement > >> --------------------------------------------------------------------- > > > > +1000000! Fantastically awesome, imho. > > Thanks for the support Rex. But is there really nobody else who is > interested in this or has any comments? Either way? From either EPEL or > other repos? I won't be offended if everyone thinks it's a waste of time > and energy, but I was hoping that it might offer a positive way forward > and any constructive comments are welcome. Thanks for the time you took to write this. It was a breath of fresh air and very positive. I would support it. There is nothing there (I think) that I'm already not doing (sigh, or at least doing my best to do...). -- Fernando (Planet CCRMA) From mastahnke at gmail.com Sat May 12 20:02:15 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 12 May 2007 15:02:15 -0500 Subject: From the Summit In-Reply-To: <4645F191.9030209@redhat.com> References: <4645F191.9030209@redhat.com> Message-ID: <7874d9dd0705121302s360fbec3s31480b95d1fc6e25@mail.gmail.com> After I saw rhx launch (on redhat.com) I too thought all of those applications should be in Fedora at least. I was sad to find the 3 I was looking at were not packaged for Fedora. I might look into packaging one or two of them, though since I know little about them at this point, I might not be the greatest fit. Either way, glad to hear there was some interest regarding EPEL at the summit. Thanks for the update Mike! stahnma On 5/12/07, Mike McGrath wrote: > The summit is done and I actually heard a few questions about EPEL from > some of those attending. Shortly after our Fedora QA session someone > approached me regarding the new Red Hat Exchange stuff > (rhx.redhat.com). Some ideas included looking into handing packaging of > some enterprise apps out in the open by the vendors using our packaging > standards. It was interesting and nice to hear that we're getting > around and raising eyebrows, I thought I'd pass that along. > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Sun May 13 08:06:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 10:06:15 +0200 Subject: EPEL report 2007, week 19 In-Reply-To: <1178996675.12610.14.camel@cmn3.stanford.edu> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> Message-ID: <4646C6F7.4020607@leemhuis.info> Fernando Lopez-Lezcano schrieb: > On Sat, 2007-05-12 at 15:10 +0200, Thorsten Leemhuis wrote: >> Josh Boyer schrieb: >>>> * repotags -- some discussion in the meeting again. It looks like it >>>> will we'll continue without repotags (final decision probably in next >>>> weeks meeting, after this summary has been posted and discussed). If you >>>> want repotags please *speak up now* > I do. But maybe you are just asking for "I do"'s from list participants > that do not have a third party repo? Actually I'm interested in opnions from everyone; but I'm especially interested in opnions from Fedora/EPEL contributos. > Rationale for support has been > already hashed to death in many threads. And others that don't see a sense or benefit in repotags (or even think they do harm) have expressed their opinion as well. >>>> and *help* to find a technical >>>> solution that is not only fine for the EPEL Steering Committee, but also >>>> acceptable for the Fedora Packaging Committee and FESCo -- from >>>> discussions on list and on IRC it looks like that some members of those >>>> groups tend to be against using repotags (see this weeks FESCo meeting >>>> for example) or want to see something cooperation statements signed by >>>> EPEL and 3rd party repos before they are willing to accept repotags. >>> Just some clarification. Yes, FESCo overall didn't see a good reason to >>> use repotags. If EPEL chooses to do so, FESCo won't stand in the way. >> FYI: I was a bit against repotags in the past, but my position these >> days after all this discussions is similar. >> Or, to be more verbose: If someone works out the details on how to >> realize repotags in Fedora then (depending on how the proposal looks >> like) I'll likely abstain from a vote or might even support to use >> repotags, as long as a simple "cp FC-6/foo.spec EL-5/" remains possible. >> But I don't have the energy to work out the details. Anyone willing to >> work them out? > > I presume this is internal help? (meaning how to tweak the build system > to support them transparently without any impact to the spec files > themselves?) No, more meaning: Find a technical and political solution that is acceptable for EPEL SIG and the Fedora Packaging Committee (and FESCo, if it wants to ). And let me warn you: there seems to be a opposition against repotags on that way from what I can see, so this process might take weeks and likely lots of discussions and mails. There are high chances to get frustrated and burned out on the way afaics. Actually realizing what got decided in the end is probably easy. CU thl From fedora at leemhuis.info Sun May 13 08:12:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 10:12:49 +0200 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <464465D1.6040501@timj.co.uk> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> Message-ID: <4646C881.30103@leemhuis.info> Tim Jackson schrieb: > Rex Dieter wrote: > >> Tim Jackson wrote: > --------------------------------------------------------------- >>> Repository Community Collaboration Statement >>> --------------------------------------------------------------------- >> +1000000! Fantastically awesome, imho. > Thanks for the support Rex. But is there really nobody else who is > interested in this or has any comments? Either way? From either EPEL or > other repos? I won't be offended if everyone thinks it's a waste of time > and energy, but I was hoping that it might offer a positive way forward > and any constructive comments are welcome. I'm actually a bit unsure myself about that and was watching what comments show up before commenting myself. My biggest concern: I think a "Repository Community Collaboration Statement" nothing that should be specific to EPEL. On the Fedora-site it should be signed by Fedora itself, to cover both Fedora repos and EPEL. Thus FESCo or the Board is likely the better place to go. As Rex is in both Committee's he's maybe a good person to poke ;-) CU thl From fedora at leemhuis.info Sun May 13 12:45:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 14:45:28 +0200 Subject: Open tasks Message-ID: <46470868.6030907@leemhuis.info> Hi, Just FYI, I updated the Schedule in the wiki to be a bit more up2date http://fedoraproject.org/wiki/EPEL/Schedule It was a bit out of date and I hoope it's in a better shape now -- more stuff is likely to be added over the next days and weeks. In the future I'll try harder to keep it up2date properly. BTW, there are two task could really need someone to drive them: * Finish the wiki -- knurd did some updates and enhancements to the EPEL space in the wiki; at least two people from the SIG or the Steering Committee should review it; then we'll remove the "This is currently a being worked on and not yet finished" warnings * Repolayout -- we need the testing repo in place and agree on the final layout; adjust the release rpms accordingly. Do we need bodhi for it? Or can tricks with the current push scripts suffice? Any volunteers to help with getting those tasks done? Cu thl From sundaram at fedoraproject.org Sun May 13 15:54:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 13 May 2007 21:24:34 +0530 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4646C881.30103@leemhuis.info> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> <4646C881.30103@leemhuis.info> Message-ID: <464734BA.1060006@fedoraproject.org> Thorsten Leemhuis wrote: > Tim Jackson schrieb: >> Rex Dieter wrote: >> >>> Tim Jackson wrote: >> --------------------------------------------------------------- >>>> Repository Community Collaboration Statement >>>> --------------------------------------------------------------------- >>> +1000000! Fantastically awesome, imho. >> Thanks for the support Rex. But is there really nobody else who is >> interested in this or has any comments? Either way? From either EPEL or >> other repos? I won't be offended if everyone thinks it's a waste of time >> and energy, but I was hoping that it might offer a positive way forward >> and any constructive comments are welcome. > > I'm actually a bit unsure myself about that and was watching what > comments show up before commenting myself. > > My biggest concern: I think a "Repository Community Collaboration > Statement" nothing that should be specific to EPEL. On the Fedora-site > it should be signed by Fedora itself, to cover both Fedora repos and > EPEL. Thus FESCo or the Board is likely the better place to go. As Rex > is in both Committee's he's maybe a good person to poke ;-) Yep. Individual maintainers shouldn't be asked to sign on a document like this. We have to make a project wide policy on this. It is just common sense guidelines. There is nothing inherently EPEL specific about third party repository collaboration. On Fedora excluding EPEL most of the active maintainers of third party repository are already working with the project (atrpms, freshrpms, kde-redhat etc) and there is a separate effort to have rest of the packages that don't fit into Fedora's legal requirements into a single third party repository too. A similar situation for third party repositories for EL would be very good for both contributors and end users. If third party repos have very different policies, it should be transparent to end users what the target audience and level of collaboration is. Rahul From sundaram at fedoraproject.org Sun May 13 18:10:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 13 May 2007 23:40:22 +0530 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4634A1A8.7070903@timj.co.uk> References: <4634A1A8.7070903@timj.co.uk> Message-ID: <4647548E.3040907@fedoraproject.org> Tim Jackson wrote: > I have a feeling I might regret this, but if nobody tries.... > > I have written up below a proposed simple statement of collaboration > which ideally a number of interested parties in different repositories > (EPEL, Fedora, RPMforge, AT etc.) could sign up to. > > At this stage I'm interested mostly in whether people like the broad > principle, rather than picking apart specific wording as I'd rather this > didn't descend into a discussion about semantics or politics. Basically: > is this something that people feel could form the basis of something > they'd be willing to sign up to? Or should we all just go back to > arguing about repotags? I have made some changes essentially converting this from a statement that individual contributors would have to sign to a project wide policy http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration If folks are happy with it I will help drive this through FESCo and Fedora Project board after getting some feedback. Any further comments? Rahul From pertusus at free.fr Sun May 13 19:40:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 13 May 2007 21:40:11 +0200 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4647548E.3040907@fedoraproject.org> References: <4634A1A8.7070903@timj.co.uk> <4647548E.3040907@fedoraproject.org> Message-ID: <20070513194011.GF7203@free.fr> On Sun, May 13, 2007 at 11:40:22PM +0530, Rahul Sundaram wrote: > > If folks are happy with it I will help drive this through FESCo and > Fedora Project board after getting some feedback. Any further comments? Something I liked in the previous proposal was that it could also apply to other repo maintainers (unless I don't remember well). Now it seems to be fedora centric. -- Pat From sundaram at fedoraproject.org Sun May 13 20:02:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 01:32:56 +0530 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <20070513194011.GF7203@free.fr> References: <4634A1A8.7070903@timj.co.uk> <4647548E.3040907@fedoraproject.org> <20070513194011.GF7203@free.fr> Message-ID: <46476EF0.40007@fedoraproject.org> Patrice Dumas wrote: > On Sun, May 13, 2007 at 11:40:22PM +0530, Rahul Sundaram wrote: >> If folks are happy with it I will help drive this through FESCo and >> Fedora Project board after getting some feedback. Any further comments? > > Something I liked in the previous proposal was that it could also apply > to other repo maintainers (unless I don't remember well). Now it seems > to be fedora centric. If the goal is to get other repository maintainers we need to get them to agree to it specifically. We can't impose that without their explicit support. This policy page IMO is purely from the Fedora project perspective that we do ack that such collaboration is a good idea. I don't think there is any question whatsoever that third party repository maintainer's would support such a policy statement. Nevertheless I have added a additional section to gather feedback. Rahul From lists at timj.co.uk Mon May 14 06:03:59 2007 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 14 May 2007 07:03:59 +0100 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4646C881.30103@leemhuis.info> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> <4646C881.30103@leemhuis.info> Message-ID: <4647FBCF.3060404@timj.co.uk> Thorsten Leemhuis wrote: > My biggest concern: I think a "Repository Community Collaboration > Statement" nothing that should be specific to EPEL. I agree. What's the concern? My proposal had nothing to do with EPEL in it. OK, it mentioned Fedora/RHEL derived distros, but it was intentionally repo-agnostic. > On the Fedora-site it should be signed by Fedora itself, to cover > both Fedora repos and EPEL. Yes. Tim From lists at timj.co.uk Mon May 14 06:05:27 2007 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 14 May 2007 07:05:27 +0100 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <464734BA.1060006@fedoraproject.org> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> <4646C881.30103@leemhuis.info> <464734BA.1060006@fedoraproject.org> Message-ID: <4647FC27.2010105@timj.co.uk> Rahul Sundaram wrote: >> My biggest concern: I think a "Repository Community Collaboration >> Statement" nothing that should be specific to EPEL. On the Fedora-site >> it should be signed by Fedora itself, to cover both Fedora repos and >> EPEL. Thus FESCo or the Board is likely the better place to go. As Rex >> is in both Committee's he's maybe a good person to poke ;-) > > Yep. Individual maintainers shouldn't be asked to sign on a document > like this. Of course not. That certainly wasn't my intention. "Signatories" was intended to be a list, like: - EPEL - Fedora Project (or whatever) - Some Third Party Project - Some Other Third Party Project *not* individual contributors. Tim From lists at timj.co.uk Mon May 14 06:14:29 2007 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 14 May 2007 07:14:29 +0100 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4647548E.3040907@fedoraproject.org> References: <4634A1A8.7070903@timj.co.uk> <4647548E.3040907@fedoraproject.org> Message-ID: <4647FE45.9060307@timj.co.uk> Rahul Sundaram wrote: > I have made some changes essentially converting this from a statement > that individual contributors would have to sign to a project wide policy > > http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration > > If folks are happy with it I will help drive this through FESCo and > Fedora Project board after getting some feedback. Any further comments? I'm a bit concerned that you've undermined one of the base principles of my proposal Rahul. I put a lot of thought into *specifically* wording it so that it could be "signed" by any project. You've now turned it round and made it Fedora centric, so it doesn't make sense for another repo to sign. I can't see the sense in that. (It doesn't make sense for Dag, for example, to sign a statement saying "Fedora Project agrees to XXX"). That's why I repeatedly referred to "the signatories" rather than "Fedora Project". That's the only way to get a document which multiple people can all sign up to and make equal committments to. This is supposed to be a mutual thing. By all means, it would make sense for fedoraproject.org to have a reference to the (neutral) signed agreement and say "this is how we, one of the signatories, are implementing it". But it doesn't make sense to change the core doc. (Incidentally, the implication is that the actual core doc should probably *not* be on fedoraproject.org, to avoid confusion. If we get a final agreed version then I am happy to host it separately) So I'd prefer it if we could go back to the neutral version. Tim From fedora at leemhuis.info Mon May 14 06:27:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 May 2007 08:27:35 +0200 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4647FBCF.3060404@timj.co.uk> References: <4634A1A8.7070903@timj.co.uk> <464465D1.6040501@timj.co.uk> <4646C881.30103@leemhuis.info> <4647FBCF.3060404@timj.co.uk> Message-ID: <46480157.3070001@leemhuis.info> On 14.05.2007 08:03, Tim Jackson wrote: > Thorsten Leemhuis wrote: > >> My biggest concern: I think a "Repository Community Collaboration >> Statement" nothing that should be specific to EPEL. > I agree. What's the concern? [...] The concern is issued was this: >> On the Fedora-site it should be signed by Fedora itself, to cover > > both Fedora repos and EPEL. So it should in addition be discussed somewhere else and not on the epel-specific list, where most Fedora-Contributors don't see it. But we are trying to solve a issue that came up here, so in parts it's okay to discuss it here, too. But we still don't know what Dag, Axel and others think about it... CU thl From sundaram at fedoraproject.org Mon May 14 14:38:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 20:08:11 +0530 Subject: Proposal: Repository Community Collaboration Statement In-Reply-To: <4647FE45.9060307@timj.co.uk> References: <4634A1A8.7070903@timj.co.uk> <4647548E.3040907@fedoraproject.org> <4647FE45.9060307@timj.co.uk> Message-ID: <46487453.6060905@fedoraproject.org> Tim Jackson wrote: > Rahul Sundaram wrote: > >> I have made some changes essentially converting this from a statement >> that individual contributors would have to sign to a project wide policy >> >> http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration >> >> If folks are happy with it I will help drive this through FESCo and >> Fedora Project board after getting some feedback. Any further comments? > > I'm a bit concerned that you've undermined one of the base principles of > my proposal Rahul. I put a lot of thought into *specifically* wording it > so that it could be "signed" by any project. You've now turned it round > and made it Fedora centric, so it doesn't make sense for another repo to > sign. I can't see the sense in that. (It doesn't make sense for Dag, for > example, to sign a statement saying "Fedora Project agrees to XXX"). If it involved a Fedora effort and if is the Fedora wiki it is already very Fedora centric. If you read the proposal it only requires a ack from third party repository maintainers that this is what they desire. If you want to go back to the older proposal you can revert the wiki. Rahul From fedora at leemhuis.info Tue May 15 15:24:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 17:24:03 +0200 Subject: Update strategy (was: Re: TestDisk in EPEL ?) In-Reply-To: References: <46472F24.6070801@leemhuis.info> Message-ID: <4649D093.1090409@leemhuis.info> Hi all! I got below mail in private and wanted to discuss it here in the open (got permission from the Christophe to forward his mail here). On 13.05.2007 21:16, Christophe GRENIER wrote: > On Sun, 13 May 2007, Thorsten Leemhuis wrote: >> Building you Fedora packages for EPEL (Extra Packages for Enterprise >> Linux -- http://fedoraproject.org/wiki/EPEL ) is possible for some >> months now. But it seem lots of Fedora contributors wait for a kind of >> start signal to begin. *This mail is this start signal*, as we have all >> the important pieces in place now! So go and build your Fedora packages >> for EPEL if you want, to have your packages easily available for RHEL >> and compatible derivates such as CentOS or Scientific Linux in the >> future as well! >> ... >> Is EPEL a rolling release like Fedora Extras was? No, the plan is to >> have a update strategy similar to the one from RHEL. E.g. ship software >> once and only update it to later versions if there is a strong need -- >> so no "hey, there is a new version, it builds, let's ship it" mentality >> in EPEL please. See >> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for more details. > [...] > I think that TestDisk and PhotoRec should be avaible for RedHat Enterprise > but as they are recovery utilities , it's usually/always better to use > latest version. Should I request an EPEL branch and update to new > version (if recovery has been improved) 2/3 weeks after fc-devel package ? My 2 cent: * updates always bear risks. * updates especially bear risks if the combination of app + libs + kernel is not tested much. That happens in RHEL quickly, as libs and kernel are not moving much (while app moves and will likely get testing with more recent libs and kernels). * users choose RHEL because it doesn't move much -- why should a add-on repo be different? * there are "recovery utilities" in RHEL5 -- but even those only get updates if there is a good reasons to So my answer for this specific app would be: if there are minor TestDisk versions (e.g. from 6.6-1.fc7 to 6.6-2 or 6.7-2) that *mainly* fix bugs released over the next 2 or 3 years then feel free to update them in EPEL *if* there is a really good reason for it. Major new versions that that change behavior (e.g. command line options for example) should be avoid if possible. After RHEL6 is out and settled for a while only touch the RHEL5 TestDisk package if there is a strong need to and avoid even minor versions. That round about what http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies says afaics. Other opinions? Cu thl From fedora at leemhuis.info Tue May 15 17:33:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 19:33:42 +0200 Subject: Topics for tomorrows (20070515) EPEL SIG Meeting Message-ID: <4649EEF6.5060006@leemhuis.info> Hi all! Here are the main topics for tomorrows EPEL SIG Meeting (17:00 UTC, #fedora-meeting on freenode): /topic EPEL Meeting -- repotags/interaction with 3rd party repos -- owner: all /topic EPEL Meeting -- vacant seat in the steering committee /topic EPEL Meeting -- Investigate single RHEL subscription for EPEL maintainers -- quaid /topic EPEL Meeting -- finish the wiki docs and remove the warnings /topic EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid Anything else we should discuss? FYI regarding the "vacant seat in the steering committee" topic -- I mailed the five people Axel suggested in private; I didn't get a "yes I'll be gladly willing to be a members of the Steering Committee" kind of reply yet. So we'd likely need another week to find someone. Self-nomination in private or public from interested people would be appreciated! CU thl From pertusus at free.fr Tue May 15 20:58:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 22:58:34 +0200 Subject: Update strategy (was: Re: TestDisk in EPEL ?) In-Reply-To: <4649D093.1090409@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> Message-ID: <20070515205834.GE2828@free.fr> On Tue, May 15, 2007 at 05:24:03PM +0200, Thorsten Leemhuis wrote: > > Other opinions? I think it would be nice to have more discussions on the epel list where people ask others whether it is interestig to add a package, or risky because it will leave a high burden on the epel maintainers or deceive users. -- Pat From smooge at gmail.com Tue May 15 21:13:04 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 15 May 2007 15:13:04 -0600 Subject: Update strategy (was: Re: TestDisk in EPEL ?) In-Reply-To: <4649D093.1090409@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> Message-ID: <80d7e4090705151413u170c483ah42d782ddc9d958cf@mail.gmail.com> On 5/15/07, Thorsten Leemhuis wrote: > Hi all! > > I got below mail in private and wanted to discuss it here in the open > (got permission from the Christophe to forward his mail here). > > On 13.05.2007 21:16, Christophe GRENIER wrote: > > On Sun, 13 May 2007, Thorsten Leemhuis wrote: > >> Building you Fedora packages for EPEL (Extra Packages for Enterprise > >> Linux -- http://fedoraproject.org/wiki/EPEL ) is possible for some > >> months now. But it seem lots of Fedora contributors wait for a kind of > >> start signal to begin. *This mail is this start signal*, as we have all > >> the important pieces in place now! So go and build your Fedora packages > >> for EPEL if you want, to have your packages easily available for RHEL > >> and compatible derivates such as CentOS or Scientific Linux in the > >> future as well! > >> ... > >> Is EPEL a rolling release like Fedora Extras was? No, the plan is to > >> have a update strategy similar to the one from RHEL. E.g. ship software > >> once and only update it to later versions if there is a strong need -- > >> so no "hey, there is a new version, it builds, let's ship it" mentality > >> in EPEL please. See > >> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for more details. > > [...] > > I think that TestDisk and PhotoRec should be avaible for RedHat Enterprise > > but as they are recovery utilities , it's usually/always better to use > > latest version. Should I request an EPEL branch and update to new > > version (if recovery has been improved) 2/3 weeks after fc-devel package ? > > My 2 cent: > > * updates always bear risks. > > * updates especially bear risks if the combination of app + libs + > kernel is not tested much. That happens in RHEL quickly, as libs and > kernel are not moving much (while app moves and will likely get testing > with more recent libs and kernels). > > * users choose RHEL because it doesn't move much -- why should a add-on > repo be different? > Ok my experience supporting RHEL at two government laboratories and talking with people at large organizations. There are multiple audiences for add-on repos that follow the classic markets (http://en.wikipedia.org/wiki/Crossing_the_Chasm): innovators, early adopters, early majority, late majority, and laggards. The innovators were the people who had to have RHEL-2.1 due to a programatic reason (the core app would only work on 2.1) but needed also the latest php modules on it. We could not support this directly, but helped out with a repository where they could put in alternative packages to replace items til they got what they wanted. Or they wanted RHEL-5 with Thunderbird-2.x. Or they are putting a 2.4.30+ kernel on 2.1 etc. They normally use Fedora/etc but cant in some situations and innovate to make it work. The early adopters wanted RHEL-5 with additional items and some level of replacement. They wanted the newest version of say moin, clustering application etc as they are usually wanting the best new experience for their 'customers'... but want more stability in the backend. Most are served by a Fedora or the Red Hat Global Desktop.. but may need a core set of items (glibc/kernel) stable for some programmatic reason The early majority wants stability with updates occuring at known times. They want technology refreshes, but want a seal of approval of some sort that the organization is steady, has standards, or has a company that will stand behind it. They also want the same thing as close to possible on as many of their systems (as they will have RHEL-3,4, and 5 deployed as servers that they want to add stuff to). The late majority want stability over anything. They are the ones who are starting to cycle out RHEL-1 and RHEL-2.1 systems to 4 systems when they get new hardware. They want to have the same version of moin supported for 7 years (just in case they need to keep a server that long up). The laggards are moving from RHL-6.2 to maybe RHL-3.9 or RHL-4.5 in the next couple of years. If they want external stuff, they will have Oracle/IBM/etc do it for them. Which of the customer bases does EPEL want to look at? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From buildsys at fedoraproject.org Wed May 16 12:12:25 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 16 May 2007 08:12:25 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-16 Message-ID: <20070516121225.10F86152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 21 NEW autodir-0.99.9-2.el5 : Creates user directories on demand NEW DMitry-1.3a-2.el5 : Deepmagic Information Gathering Tool NEW ike-scan-1.9-3.el5 : IKE protocol tool to discover, fingerprint and test IPsec VPN servers NEW nbtscan-1.5.1-1.el5 : Tool to gather NetBIOS info from Windows networks NEW ocaml-3.09.3-1.el5 : Objective Caml compiler and programming environment NEW pdns-2.9.21-1.el5 : A modern, advanced and high performance authoritative-only nameserver NEW perl-DBD-SQLite-1.12-2.el5 : Self Contained RDBMS in a DBI Driver NEW perl-IO-Multiplex-1.08-5.el5 : IO-Multiplex module for perl NEW perl-libwhisker2-2.4-2.el5 : Perl module geared specificly for HTTP testing NEW php-channel-phpunit-1.0-2.el5 : Adds phpunit channel to PEAR NEW php-pear-File-Passwd-1.1.6-2.el5 : Manipulate many kinds of password files NEW php-pear-File-SMBPasswd-1.0.2-1.el5 : Class for managing SAMBA style password files NEW php-pecl-radius-1.2.4-2.el5 : Radius client library NEW php-pecl-xdebug-2.0.0-0.5.RC2.el5 : PECL package for debugging PHP scripts NEW python-cheetah-2.0-0.6.rc8.el5 : Template engine and code-generator NEW python-krbV-1.0.13-5.el5 : Python extension module for Kerberos 5 NEW python-protocols-1.0-0.3.a0dev_r2082.el5 : Open Protocols and Component Adaptation for Python NEW python-sqlite2-2.3.3-1.el5 : DB-API 2.0 interface for SQLite 3.x rpmlint-0.80-1.el5 NEW scponly-4.6-6.el5 : Restricted shell for ssh based file services NEW windowlab-1.34-6.el5 : Small and Simple Amiga-like Window Manager Packages built and released for Fedora EPEL 4: 9 crack-5.0a-2.el4 NEW DMitry-1.3a-2.el4 : Deepmagic Information Gathering Tool NEW ike-scan-1.9-3.el4 : IKE protocol tool to discover, fingerprint and test IPsec VPN servers NEW nbtscan-1.5.1-2.el4 : Tool to gather NetBIOS info from Windows networks NEW ocaml-3.09.2-1.el4 : Objective Caml compiler and programming environment NEW perl-libwhisker2-2.4-2.el4 : Perl module geared specificly for HTTP testing NEW python-krbV-1.0.13-5.el4 : Python extension module for Kerberos 5 NEW scponly-4.6-5.el4 : Restricted shell for ssh based file services NEW windowlab-1.34-6.el4 : Small and Simple Amiga-like Window Manager Changes in Fedora EPEL 5: autodir-0.99.9-2.el5 -------------------- * Mon May 07 2007 Matthias Saou 0.99.9-2 - Add missing scriplets requirements. - Update sf.net source URL. - Switch away from %makeinstall. * Wed Apr 18 2007 Matthias Saou 0.99.9-1 - Update to 0.99.9. DMitry-1.3a-2.el5 ----------------- * Sat May 12 2007 Sindre Pedersen Bj?rdal - 1.3a-2 - Bump release for rebuild * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.3a-1 - Initial build ike-scan-1.9-3.el5 ------------------ * Sun May 13 2007 Sindre Pedersen Bj?rdal - 1.9-3 - bump release for rebuild * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.9-2 - Add openssl support * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.9-1 - Initial build nbtscan-1.5.1-1.el5 ------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 1.5.1-1 - Initial build ocaml-3.09.3-1.el5 ------------------ * Sat Dec 02 2006 Gerard Milmeister - 3.09.3-1 - new version 3.09.3 pdns-2.9.21-1.el5 ----------------- * Tue May 01 2007 Ruben Kerkhof 2.9.21-1 - Upstream released 2.9.21 - Enabled new SQLite backend perl-DBD-SQLite-1.12-2.el5 -------------------------- * Thu Sep 14 2006 Jose Pedro Oliveira - 1.12-2 - Rebuild for FC6. perl-IO-Multiplex-1.08-5.el5 ---------------------------- * Fri Sep 15 2006 Leif O M Bergman - 1.08-5 - Add dist tag perl-libwhisker2-2.4-2.el5 -------------------------- * Tue May 08 2007 Sindre Pedersen Bj?rdal - 2.4-2 - Fix typo in Source0 url - Update lw1bridge patch to not include License info - Add explicit version to Provides and Obsoletes - Added tests, commented out - Cleaned up BuildRequires and Requires * Fri May 04 2007 Sindre Pedersen Bj?rdal - 2.4-1 - Initial build php-channel-phpunit-1.0-2.el5 ----------------------------- * Fri Dec 29 2006 Christopher Stone 1.0-2 - Add virtual provides on channel name php-pear-File-Passwd-1.1.6-2.el5 -------------------------------- * Sun May 13 2007 Christopher Stone 1.1.6-2 - Include samba extension as default for Fedora - Exclude samba extension from Enterprise Linux php-pear-File-SMBPasswd-1.0.2-1.el5 ----------------------------------- * Tue Mar 13 2007 Christopher Stone 1.0.2-1 - Initial Fedora release php-pecl-radius-1.2.4-2.el5 --------------------------- * Sun Mar 11 2007 Christopher Stone 1.2.4-2 - Use new ABI check for FC-6 - Create directory to untar sources - Remove %{release} from Provides php-pecl-xdebug-2.0.0-0.5.RC2.el5 --------------------------------- * Sun Mar 11 2007 Christopher Stone 2.0.0-0.5.RC2 - Create directory to untar sources - Use new ABI check for FC6 - Remove %{release} from Provides python-cheetah-2.0-0.6.rc8.el5 ------------------------------ * Thu May 03 2007 Mike Bonnet - 2.0-0.6.rc8 - bump release for rebuild * Mon Apr 23 2007 Mike Bonnet - 2.0-0.5.rc8 - update to 2.0rc8 python-krbV-1.0.13-5.el5 ------------------------ * Mon Dec 11 2006 Mike Bonnet - 1.0.13-5 - remove obsolete python-abi Requires: python-protocols-1.0-0.3.a0dev_r2082.el5 ---------------------------------------- * Sat Sep 16 2006 Shahms E. King 1.0-0.3-a0dev_r2082 - Rebuild for FC6 python-sqlite2-2.3.3-1.el5 -------------------------- * Tue Mar 13 2007 Dawid Gajownik - 1:2.3.3-1 - Update to 2.3.3 (#231848) rpmlint-0.80-1.el5 ------------------ * Thu Apr 12 2007 Ville Skytt? - 0.80-1 - 0.80, fixes #227389, #228645, #233795. - Accept "Redistributable, no modification permitted" as a valid license. - Filter messages about doc file dependencies on /bin/sh. - Add missing dependency on file. scponly-4.6-6.el5 ----------------- * Fri Sep 15 2006 Warren Togami - 4.6-6 - rebuild for FC6 windowlab-1.34-6.el5 -------------------- * Wed May 16 2007 Nigel Jones 1.34-6 - Bump release number to allow upgrade from EL-4 * Tue Apr 24 2007 Nigel Jones 1.34-4 - Remove executable bit on source files * Wed Apr 18 2007 Nigel Jones 1.34-3 - Honor $RPM_OPT_FLAGS - +Patch to prevent stripping of debug info Changes in Fedora EPEL 4: crack-5.0a-2.el4 ---------------- * Thu May 10 2007 Christian Iseli 5.0a-2 - Fix #239575: crack uses obsolete sort option syntax DMitry-1.3a-2.el4 ----------------- * Sat May 12 2007 Sindre Pedersen Bj?rdal - 1.3a-2 - Bump release for rebuild * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.3a-1 - Initial build ike-scan-1.9-3.el4 ------------------ * Sun May 13 2007 Sindre Pedersen Bj?rdal - 1.9-3 - bump release for rebuild * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.9-2 - Add openssl support * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.9-1 - Initial build nbtscan-1.5.1-2.el4 ------------------- * Sat May 12 2007 Sindre Pedersen Bj?rdal - 1.5.1-2 - Bump version for rebuild * Sat May 05 2007 Sindre Pedersen Bj?rdal - 1.5.1-1 - Initial build ocaml-3.09.2-1.el4 ------------------ * Sun Apr 30 2006 Gerard Milmeister - 3.09.2-1 - new version 3.09.2 perl-libwhisker2-2.4-2.el4 -------------------------- * Tue May 08 2007 Sindre Pedersen Bj?rdal - 2.4-2 - Fix typo in Source0 url - Update lw1bridge patch to not include License info - Add explicit version to Provides and Obsoletes - Added tests, commented out - Cleaned up BuildRequires and Requires * Fri May 04 2007 Sindre Pedersen Bj?rdal - 2.4-1 - Initial build python-krbV-1.0.13-5.el4 ------------------------ * Mon Dec 11 2006 Mike Bonnet - 1.0.13-5 - remove obsolete python-abi Requires: scponly-4.6-5.el4 ----------------- * Tue Jun 27 2006 Toshio Kuratomi - 4.6-5 - Add BR: openssh-server so sftp-server is present. - Make source files nonexecutable so they are nonexecutable in debuginfo. - Mark the scponly configuration files as %config. windowlab-1.34-6.el4 -------------------- * Wed May 16 2007 Nigel Jones 1.34-6 - Fix x86_64 issue for library search dir * Wed May 16 2007 Nigel Jones 1.34-5 - Build for EL-4 (Dependency change) - + Fix for X11/Xext library paths * Tue Apr 24 2007 Nigel Jones 1.34-4 - Remove executable bit on source files * Wed Apr 18 2007 Nigel Jones 1.34-3 - Honor $RPM_OPT_FLAGS - +Patch to prevent stripping of debug info For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Wed May 16 16:59:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 May 2007 18:59:12 +0200 Subject: Update strategy In-Reply-To: <80d7e4090705151413u170c483ah42d782ddc9d958cf@mail.gmail.com> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> <80d7e4090705151413u170c483ah42d782ddc9d958cf@mail.gmail.com> Message-ID: <464B3860.6020609@leemhuis.info> On 15.05.2007 23:13, Stephen John Smoogen wrote: > On 5/15/07, Thorsten Leemhuis wrote: > [...] > Ok my experience supporting RHEL at two government laboratories and > talking with people at large organizations. There are multiple > audiences for add-on repos that follow the classic markets > (http://en.wikipedia.org/wiki/Crossing_the_Chasm): innovators, early > adopters, early majority, late majority, and laggards. > > > The innovators were the people who had to have RHEL-2.1 due to a > programatic reason (the core app would only work on 2.1) but needed > also the latest php modules on it. We could not support this directly, > but helped out with a repository where they could put in alternative > packages to replace items til they got what they wanted. Or they > wanted RHEL-5 with Thunderbird-2.x. Or they are putting a 2.4.30+ > kernel on 2.1 etc. They normally use Fedora/etc but cant in some > situations and innovate to make it work. Well, as you say, those use normally Fedora or Fedora-like distribution. No need for EPEL to target those. > The early adopters wanted RHEL-5 with additional items and some level > of replacement. They wanted the newest version of say moin, clustering > application etc as they are usually wanting the best new experience > for their 'customers'... but want more stability in the backend. Most > are served by a Fedora or the Red Hat Global Desktop.. but may need a > core set of items (glibc/kernel) stable for some programmatic reason I'd say those people that only want some new apps and a stable backend are best served with a local repo for the apps they need in up2date version or other specific small repos. They can use the Fedora packages as a base for it; EPEL probably can't serve those people with todays tools (yum and co), as each and everyone defines stable backend differently. > The early majority wants stability with updates occuring at known > times. They want technology refreshes, but want a seal of approval of > some sort that the organization is steady, has standards, or has a > company that will stand behind it. They also want the same thing as > close to possible on as many of their systems (as they will have > RHEL-3,4, and 5 deployed as servers that they want to add stuff to). Those are IMHO round about one of the targets for EPEL -- even if there is no company behind EPEL, they get stuff missing in RHEL easily with EPEL. > The late majority want stability over anything. They are the ones who > are starting to cycle out RHEL-1 and RHEL-2.1 systems to 4 systems > when they get new hardware. They want to have the same version of moin > supported for 7 years (just in case they need to keep a server that > long up). They can use EPEL5 when RHEL6 or RHEL7 are out, as EPEL5 shouldn't move much anymore and be quite stable. > The laggards are moving from RHL-6.2 to maybe RHL-3.9 or RHL-4.5 in > the next couple of years. If they want external stuff, they will have > Oracle/IBM/etc do it for them. :-) > Which of the customer bases does EPEL want to look at? Hope that clarifies it. CU thl From smooge at gmail.com Wed May 16 17:54:46 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 16 May 2007 11:54:46 -0600 Subject: Update strategy In-Reply-To: <464B3860.6020609@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> <80d7e4090705151413u170c483ah42d782ddc9d958cf@mail.gmail.com> <464B3860.6020609@leemhuis.info> Message-ID: <80d7e4090705161054v47dab30bn197019825607bda3@mail.gmail.com> On 5/16/07, Thorsten Leemhuis wrote: > On 15.05.2007 23:13, Stephen John Smoogen wrote: > > The early majority wants stability with updates occuring at known > > times. They want technology refreshes, but want a seal of approval of > > some sort that the organization is steady, has standards, or has a > > company that will stand behind it. They also want the same thing as > > close to possible on as many of their systems (as they will have > > RHEL-3,4, and 5 deployed as servers that they want to add stuff to). > > Those are IMHO round about one of the targets for EPEL -- even if there > is no company behind EPEL, they get stuff missing in RHEL easily with EPEL. > I thought about this some more last night. Would the EPEL repository be better suited with an 'alternate' tree structure? X.old Last release X.stable Current release X..testing Stuff might be pushed to current release X.rawhide Stuff that might go into testing for next release. X.Y/SRPMS X.Y/ with symbolic links to show the tree structure. 4.4 -> 4.old 4.5 -> 4.stable 4.6 -> 4.testing 4.7 -> 4.rawhide This would allow people who are doing different levels of testing to aim at a said set? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Wed May 16 18:11:16 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 16 May 2007 12:11:16 -0600 Subject: wither clamav? Message-ID: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> Ok I am going to step in it big time.. but I want to have a frank discussion but try to avoid a flame-war. clamav seems to be frozen to 0.88.x for a while in Extras, but is no longer supported upstream. I understand the reason for Enricho's freezing it, but I think that I would like a more modern version of clamav in EPEL before it gets published. There are a couple of items I would like to address: 1) The versions in Fedora and RPMforge/AT have drastic differences in layout of packaging etc that cause problems for administrators. 2) There are issues with moving from 0.88 to 0.90 but they would not be an issue for a 'fresh' EPEL versioning. Is there a way for 'branching/naming' a different layout of Clamav that could be an 'import (with proper attribution) of the Forge version with changes to meet any differences between the packaging guidelines? Since I am the one sticking his bare feet into the pile of elephant diarrhea here.. I would be the sponsor, etc. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dennis at ausil.us Wed May 16 18:30:17 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 16 May 2007 13:30:17 -0500 (CDT) Subject: wither clamav? In-Reply-To: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> Message-ID: <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> > Ok I am going to step in it big time.. but I want to have a frank > discussion but try to avoid a flame-war. > > clamav seems to be frozen to 0.88.x for a while in Extras, but is no > longer supported upstream. I understand the reason for Enricho's > freezing it, but I think that I would like a more modern version of > clamav in EPEL before it gets published. There are a couple of items I > would like to address: My understanding is that Enricho does not want to support EPEL. Warren is the person who requested ClamAV for EPEL. I would say get with him work it out and make it happen. I think rebassing on the forge version is fine. -- Dennis Gilmore, RHCE From buildsys at fedoraproject.org Wed May 16 18:42:54 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 16 May 2007 14:42:54 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-16 Message-ID: <20070516184254.A950A152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 3 NEW cgdb-0.6.4-1.el5 : CGDB is a curses-based interface to the GNU Debugger (GDB) NEW nrpe-2.7-3.el5 : Host/service/network monitoring agent for Nagios NEW Pound-2.3-1.el5 : Reverse proxy and load balancer Packages built and released for Fedora EPEL 4: 1 NEW bugzilla-2.22.2-1.el4 : Bug tracking system Changes in Fedora EPEL 5: cgdb-0.6.4-1.el5 ---------------- * Wed May 16 2007 - 0.6.4-1 - 0.6.4 - Fix broken info installation. - Enable SMP build. - Preserve the source time-stamp. - Replace install with %{__install}. nrpe-2.7-3.el5 -------------- * Fri Feb 23 2007 Mike McGrath 2.7-1 - Upstream released new version Pound-2.3-1.el5 --------------- * Wed Apr 11 2007 Ruben Kerkhof 2.3-1 - Update to 2.3 Changes in Fedora EPEL 4: bugzilla-2.22.2-1.el4 --------------------- * Tue Feb 20 2007 John Berninger - 2.22.2-1 - Update to 2.22.2 - bz 229163 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From wolfy at nobugconsulting.ro Wed May 16 19:27:45 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 16 May 2007 22:27:45 +0300 Subject: wither clamav? In-Reply-To: <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> Message-ID: <464B5B31.8010904@nobugconsulting.ro> On 05/16/2007 09:30 PM, Dennis Gilmore wrote: >> Ok I am going to step in it big time.. but I want to have a frank >> discussion but try to avoid a flame-war. >> >> clamav seems to be frozen to 0.88.x for a while in Extras, but is no >> longer supported upstream. I understand the reason for Enricho's >> freezing it, but I think that I would like a more modern version of >> clamav in EPEL before it gets published. There are a couple of items I >> would like to address: >> > > My understanding is that Enricho does not want to support EPEL. Warren is > the person who requested ClamAV for EPEL. I would say get with him work > it out and make it happen. I think rebassing on the forge version is > fine. > with all due respect for Enrico's work, I give a +1 for this varioant. But... is EPEL allowed to have packages which are substantially different to those in the former FE ? From sundaram at fedoraproject.org Wed May 16 20:43:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 02:13:56 +0530 Subject: wither clamav? In-Reply-To: <464B5B31.8010904@nobugconsulting.ro> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> <464B5B31.8010904@nobugconsulting.ro> Message-ID: <464B6D0C.2030108@fedoraproject.org> Manuel Wolfshant wrote: >> > with all due respect for Enrico's work, I give a +1 for this varioant. > But... is EPEL allowed to have packages which are substantially > different to those in the former FE ? Yes. This is a different branch. While maintaining the spec files close to Fedora Package Collection is a good goal it is pretty much impossible to do it in all cases due the different release strategies between these repositories. It would be good to discuss with the Fedora package maintainer before deviating however because you are going to take up more maintenance work every time you do that and this is going to affect future releases too. Rahul From pertusus at free.fr Wed May 16 20:47:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 22:47:59 +0200 Subject: wither clamav? In-Reply-To: <464B6D0C.2030108@fedoraproject.org> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> <464B5B31.8010904@nobugconsulting.ro> <464B6D0C.2030108@fedoraproject.org> Message-ID: <20070516204759.GD2890@free.fr> On Thu, May 17, 2007 at 02:13:56AM +0530, Rahul Sundaram wrote: > > Yes. This is a different branch. While maintaining the spec files close > to Fedora Package Collection is a good goal it is pretty much impossible > to do it in all cases due the different release strategies between these > repositories. It would be good to discuss with the Fedora package In that case it is not the reason behind the change, so I am not sure that this is valid. Indeed having a difference between EPEL and F branches to accomodate third party repository in EPEL doesn't seems that right (I am not saying that we shouldn't accomodate for third party repository, but that we should do the same for that matter in EPEL and Fedora). > maintainer before deviating however because you are going to take up > more maintenance work every time you do that and this is going to affect > future releases too. Although it is true that it is right in the general case, for that particular case it is very doubtfull in my opinion. -- Pat From pertusus at free.fr Wed May 16 20:54:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 22:54:48 +0200 Subject: wither clamav? In-Reply-To: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> Message-ID: <20070516205448.GE2890@free.fr> On Wed, May 16, 2007 at 12:11:16PM -0600, Stephen John Smoogen wrote: > > 1) The versions in Fedora and RPMforge/AT have drastic differences in > layout of packaging etc that cause problems for administrators. > > 2) There are issues with moving from 0.88 to 0.90 but they would not > be an issue for a 'fresh' EPEL versioning. In my opinion it is righ to update to 0.90, but it is wrong to change tthe package layout without discussing it with enrico. If he agrees to use the sme layout when he updates to 0.90 or whatever version it would be fine. I think it is not an issue if the packages in Fedora and EPEL diverge because of the EPE peculiarities, but it seems wrong to me if the 2 packages diverge because a lack of agreements between co-maintainers on the package organization. -- Pat From sundaram at fedoraproject.org Wed May 16 21:14:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 02:44:40 +0530 Subject: wither clamav? In-Reply-To: <20070516204759.GD2890@free.fr> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> <464B5B31.8010904@nobugconsulting.ro> <464B6D0C.2030108@fedoraproject.org> <20070516204759.GD2890@free.fr> Message-ID: <464B7440.5040406@fedoraproject.org> Patrice Dumas wrote: > On Thu, May 17, 2007 at 02:13:56AM +0530, Rahul Sundaram wrote: >> Yes. This is a different branch. While maintaining the spec files close >> to Fedora Package Collection is a good goal it is pretty much impossible >> to do it in all cases due the different release strategies between these >> repositories. It would be good to discuss with the Fedora package > > In that case it is not the reason behind the change, so I am not sure > that this is valid. Indeed having a difference between EPEL and F > branches to accomodate third party repository in EPEL doesn't seems that > right (I am not saying that we shouldn't accomodate for third party > repository, but that we should do the same for that matter in EPEL and > Fedora). Which is why I suggested talking to the maintainer first which you trimmed out. Rahul From pertusus at free.fr Wed May 16 21:15:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 23:15:06 +0200 Subject: wither clamav? In-Reply-To: <464B7440.5040406@fedoraproject.org> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> <464B5B31.8010904@nobugconsulting.ro> <464B6D0C.2030108@fedoraproject.org> <20070516204759.GD2890@free.fr> <464B7440.5040406@fedoraproject.org> Message-ID: <20070516211506.GH2890@free.fr> On Thu, May 17, 2007 at 02:44:40AM +0530, Rahul Sundaram wrote: > > Which is why I suggested talking to the maintainer first which you > trimmed out. I read your mail a bit too fast, your response was in fact completly right, sorry for the noise. -- Pat From eric.tanguy at univ-nantes.fr Wed May 16 21:39:26 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Wed, 16 May 2007 23:39:26 +0200 Subject: Build problem Message-ID: <1179351566.11111.5.camel@bureau.maison> I just try to build my packages for EPEL4 and 5. Building dr-geo for EPEL4, i have this error : checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool error: Bad exit status from /var/tmp/rpm-tmp.30241 (%build) I don't have this with EPEL5. In fedora perl-XML-Parser is in core but i don't know if RHEL have this package and if i go to ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS i can see perl-XML-Parser-2.34-5.src.rpm so it would be correct. Where is the problem ? Thanks Eric From eric.tanguy at univ-nantes.fr Wed May 16 21:57:05 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Wed, 16 May 2007 23:57:05 +0200 Subject: fedora-usermgmt Message-ID: <1179352625.11111.9.camel@bureau.maison> Is fedora-usermgmt part of RHEL or EPEL 4 and 5 ? If not what we have to replace it ? Thanks Eric From steve at silug.org Wed May 16 22:56:08 2007 From: steve at silug.org (Steven Pritchard) Date: Wed, 16 May 2007 17:56:08 -0500 Subject: wither clamav? In-Reply-To: <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> Message-ID: <20070516225608.GA21782@osiris.silug.org> On Wed, May 16, 2007 at 01:30:17PM -0500, Dennis Gilmore wrote: > My understanding is that Enricho does not want to support EPEL. Warren is > the person who requested ClamAV for EPEL. I would say get with him work > it out and make it happen. I think rebassing on the forge version is > fine. And I think that would cause me (as the maintainer of amavisd-new) a great deal of pain. If I have to, I'll maintain Enrico's clamav package in EPEL. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From dev at nigelj.com Wed May 16 23:27:55 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 17 May 2007 11:27:55 +1200 (NZST) Subject: Build problem In-Reply-To: <1179351566.11111.5.camel@bureau.maison> References: <1179351566.11111.5.camel@bureau.maison> Message-ID: <11590.202.74.202.139.1179358075.squirrel@webmail.nigelj.com> > I just try to build my packages for EPEL4 and 5. > Building dr-geo for EPEL4, i have this error : > checking for XML::Parser... configure: error: XML::Parser perl module is > required for intltool > error: Bad exit status from /var/tmp/rpm-tmp.30241 (%build) Just wondering, do you have an explicit BR on perl-XML-Parser? N.J. From sheltren at cs.ucsb.edu Wed May 16 23:44:03 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 16 May 2007 19:44:03 -0400 Subject: fedora-usermgmt In-Reply-To: <1179352625.11111.9.camel@bureau.maison> References: <1179352625.11111.9.camel@bureau.maison> Message-ID: <86F3315D-0D2E-4009-B5D4-2BC18ED97B14@cs.ucsb.edu> On May 16, 2007, at 5:57 PM, Tanguy Eric wrote: > Is fedora-usermgmt part of RHEL or EPEL 4 and 5 ? > If not what we have to replace it ? > Thanks > > Eric Hi Eric, I don't think it is. This was discussed before, and I think deferred for the time being. See: https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html and https://www.redhat.com/archives/epel-devel-list/2007-April/ msg00063.html (under == MISC ==) Is there any update on this decision? -Jeff From sundaram at fedoraproject.org Thu May 17 00:23:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 05:53:10 +0530 Subject: Update strategy In-Reply-To: <4649D093.1090409@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> Message-ID: <464BA06E.5090005@fedoraproject.org> Thorsten Leemhuis wrote: > So my answer for this specific app would be: if there are minor TestDisk > versions (e.g. from 6.6-1.fc7 to 6.6-2 or 6.7-2) that *mainly* fix bugs > released over the next 2 or 3 years then feel free to update them in > EPEL *if* there is a really good reason for it. Major new versions that > that change behavior (e.g. command line options for example) should be > avoid if possible. After RHEL6 is out and settled for a while only touch > the RHEL5 TestDisk package if there is a strong need to and avoid even > minor versions. > > That round about what > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies says afaics. > > Other opinions? Though there is no formal document yet afaik describing this process in RHEL "leaf applications" are treated different from base applications. Base applications are things like libraries which are other applications depend upon. Leaf applications are things like TestDisk which is independent. Leaf applications can be updated more regularly and chances of regressions and the impact of any regressions is much less. Also in some cases heavy backporting might result in more instability compared to just updating to the newer version since such backporting is very distribution dependent and is not widely tested and used by upstream projects and the community. You might want to classify and treat applications differently and have a process for requesting exceptions if necessary. Rahul From dennis at ausil.us Thu May 17 02:01:46 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 16 May 2007 21:01:46 -0500 Subject: fedora-usermgmt In-Reply-To: <1179352625.11111.9.camel@bureau.maison> References: <1179352625.11111.9.camel@bureau.maison> Message-ID: <200705162101.46466.dennis@ausil.us> Once upon a time Wednesday 16 May 2007, Tanguy Eric wrote: > Is fedora-usermgmt part of RHEL or EPEL 4 and 5 ? > If not what we have to replace it ? > Thanks > > Eric its part of EPEL. you can use plain useradd Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Thu May 17 02:22:21 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 16 May 2007 20:22:21 -0600 Subject: wither clamav? In-Reply-To: <20070516225608.GA21782@osiris.silug.org> References: <80d7e4090705161111oa140af7u57455956581131f0@mail.gmail.com> <14225.12.163.52.126.1179340217.squirrel@webmail.ausil.us> <20070516225608.GA21782@osiris.silug.org> Message-ID: <80d7e4090705161922i64f3e6b8x6b1ce6530f91a36@mail.gmail.com> On 5/16/07, Steven Pritchard wrote: > On Wed, May 16, 2007 at 01:30:17PM -0500, Dennis Gilmore wrote: > > My understanding is that Enricho does not want to support EPEL. Warren is > > the person who requested ClamAV for EPEL. I would say get with him work > > it out and make it happen. I think rebassing on the forge version is > > fine. > > And I think that would cause me (as the maintainer of amavisd-new) a > great deal of pain. > > If I have to, I'll maintain Enrico's clamav package in EPEL. > That might be a better idea if the problems with altering the clamav packages will cause issues with other packages. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Fedora at FamilleCollet.com Thu May 17 05:49:22 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 17 May 2007 07:49:22 +0200 Subject: YUM for RHEL 4 Message-ID: <464BECE2.1080601@FamilleCollet.com> A stupid question, i probably miss something. CentOS 4 provides yum 2.4 RHEL 4 doesn't provides yum, but it is available on a very famous/usefull/high quality third party repository. How RHEL 4 users will use our new EPEL repository without yum ? Of course, if we want good collaboration, we must use the same version than dag and centos. Remi. From Michael_E_Brown at dell.com Thu May 17 06:28:00 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 17 May 2007 01:28:00 -0500 Subject: YUM for RHEL 4 In-Reply-To: <464BECE2.1080601@FamilleCollet.com> References: <464BECE2.1080601@FamilleCollet.com> Message-ID: <20070517062759.GA16994@humbolt.us.dell.com> On Thu, May 17, 2007 at 07:49:22AM +0200, Remi Collet wrote: > A stupid question, i probably miss something. > > CentOS 4 provides yum 2.4 > > RHEL 4 doesn't provides yum, but it is available on a very > famous/usefull/high quality third party repository. > > How RHEL 4 users will use our new EPEL repository without yum ? > > Of course, if we want good collaboration, we must use the same version > than dag and centos. Up2date can be trivially configured to pull packages from yum repositories. Red Hat just released RHEL 4.5 with some important fixes to up2date for bugs I found a while back. ($releasever improperly hardcoded to 3... hmmm, testing anybody?) For the Dell yum repositories, I have the 'dell-repository' RPM, which will automatically add both yum and up2date configs. -- Michael From eric.tanguy at univ-nantes.fr Thu May 17 07:32:45 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Thu, 17 May 2007 09:32:45 +0200 Subject: Build problem In-Reply-To: <11590.202.74.202.139.1179358075.squirrel@webmail.nigelj.com> References: <1179351566.11111.5.camel@bureau.maison> <11590.202.74.202.139.1179358075.squirrel@webmail.nigelj.com> Message-ID: <1179387165.11111.11.camel@bureau.maison> Le jeudi 17 mai 2007 ? 11:27 +1200, Nigel Jones a ?crit : > > I just try to build my packages for EPEL4 and 5. > > Building dr-geo for EPEL4, i have this error : > > checking for XML::Parser... configure: error: XML::Parser perl module is > > required for intltool > > error: Bad exit status from /var/tmp/rpm-tmp.30241 (%build) > Just wondering, do you have an explicit BR on perl-XML-Parser? > > No i just BR on intltool and it need perl-XML-Parser. Eric From eric.tanguy at univ-nantes.fr Thu May 17 08:31:43 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Thu, 17 May 2007 10:31:43 +0200 Subject: Mock for EPEL Message-ID: <1179390704.11111.24.camel@bureau.maison> I would like to use mock on my fc6 to test build for epel 4 and 5 but i don't have any cfg file in /etc/mock about this. How can i do this ? Thanks Eric From Fedora at FamilleCollet.com Thu May 17 09:00:36 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 17 May 2007 11:00:36 +0200 Subject: Mock for EPEL In-Reply-To: <1179390704.11111.24.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> Message-ID: <464C19B4.20008@FamilleCollet.com> Tanguy Eric a ?crit : > I would like to use mock on my fc6 to test build for epel 4 and 5 but i > don't have any cfg file in /etc/mock about this. > How can i do this ? # rpm -qf /etc/mock/*epel* mock-0.6.11-1.fc6 You probably should update your mock version. And use, p.e. mock -r fedora-4-ppc-epel You can create a fedora-5-ppc-epel using the model. Remi. From fedora at leemhuis.info Thu May 17 09:16:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 11:16:31 +0200 Subject: Mock for EPEL In-Reply-To: <464C19B4.20008@FamilleCollet.com> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> Message-ID: <464C1D6F.3050007@leemhuis.info> On 17.05.2007 11:00, Remi Collet wrote: > Tanguy Eric a ?crit : >> I would like to use mock on my fc6 to test build for epel 4 and 5 but i >> don't have any cfg file in /etc/mock about this. >> How can i do this ? > > # rpm -qf /etc/mock/*epel* > mock-0.6.11-1.fc6 > > You probably should update your mock version. > > And use, p.e. mock -r fedora-4-ppc-epel > > You can create a fedora-5-ppc-epel using the model. Or use those attached to this mail -- I send them here past week already and we'll make sure they'll get integrated into mock soon. CU thl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-i386-epel.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-x86_64-epel.cfg URL: From fedora at leemhuis.info Thu May 17 09:21:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 11:21:09 +0200 Subject: Update strategy In-Reply-To: <80d7e4090705161054v47dab30bn197019825607bda3@mail.gmail.com> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> <80d7e4090705151413u170c483ah42d782ddc9d958cf@mail.gmail.com> <464B3860.6020609@leemhuis.info> <80d7e4090705161054v47dab30bn197019825607bda3@mail.gmail.com> Message-ID: <464C1E85.10404@leemhuis.info> On 16.05.2007 19:54, Stephen John Smoogen wrote: > On 5/16/07, Thorsten Leemhuis wrote: >> On 15.05.2007 23:13, Stephen John Smoogen wrote: >>> The early majority wants stability with updates occuring at known >>> times. They want technology refreshes, but want a seal of approval of >>> some sort that the organization is steady, has standards, or has a >>> company that will stand behind it. They also want the same thing as >>> close to possible on as many of their systems (as they will have >>> RHEL-3,4, and 5 deployed as servers that they want to add stuff to). >> Those are IMHO round about one of the targets for EPEL -- even if there >> is no company behind EPEL, they get stuff missing in RHEL easily with EPEL. > I thought about this some more last night. Would the EPEL repository > be better suited with an 'alternate' tree structure? > > X.old Last release The plan is to leave all the old repos for X.X releases around; see http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee336393aec81cf6fc90543c0f2277 > X.stable Current release Sure > X..testing Stuff might be pushed to current release Under discussion -- we need to look if that's possible with bodhi. > X.rawhide Stuff that might go into testing for next release. Hmm, I'd prefer to call it X.testing X.testing-stable or something like that. > X.Y/SRPMS > X.Y/ > > with symbolic links to show the tree structure. > 4.4 -> 4.old > 4.5 -> 4.stable > 4.6 -> 4.testing > 4.7 -> 4.rawhide Might be doable. CU thl From eric.tanguy at univ-nantes.fr Thu May 17 09:30:17 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Thu, 17 May 2007 11:30:17 +0200 Subject: Mock for EPEL In-Reply-To: <464C1D6F.3050007@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> Message-ID: <1179394217.11111.26.camel@bureau.maison> Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : > > On 17.05.2007 11:00, Remi Collet wrote: > > Tanguy Eric a ?crit : > >> I would like to use mock on my fc6 to test build for epel 4 and 5 but i > >> don't have any cfg file in /etc/mock about this. > >> How can i do this ? > > > > # rpm -qf /etc/mock/*epel* > > mock-0.6.11-1.fc6 > > > > You probably should update your mock version. > > > > And use, p.e. mock -r fedora-4-ppc-epel > > > > You can create a fedora-5-ppc-epel using the model. > > Or use those attached to this mail -- I send them here past week already > and we'll make sure they'll get integrated into mock soon. > > CU > thl Thanks but i seem to have problem with mirrorlist for epel4 : $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm init clean prep This may take a while not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - Index of / not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping - CentOS Icon not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - CentOS Logo not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
 CentOS on the Web: Mailing Lists | Mirror List | IRC | Forums | Bugs | Donate
not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
[ICO]NameLast modifiedSizeDescription
[ ]TIME17-May-2007 09:10 11
[DIR]centos-2/15-Sep-2005 23:34 -
[DIR]centos-3/06-Sep-2006 11:31 -
[DIR]centos-4/15-May-2007 20:47 -
[DIR]centos-5/15-Apr-2007 11:46 -
[DIR]centos/15-May-2007 11:47 -
[DIR]mirrorscripts/12-Apr-2006 08:42 -
[TXT]server.id22-Sep-2004 15:24 0 centosc2
[TXT]timestamp.txt17-May-2007 09:10 29
not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping - not using ftp, http[s], or file for repos, skipping -
 This CentOS server donated by: Fasthosts Internet Ltd I want to donate a server: Contact us
not using ftp, http[s], or fiError: Cannot find a valid baseurl for repo: core le for repos, skipping -
not using ftp, http[s], or file for repos, skipping - Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build ending done From dev at nigelj.com Thu May 17 09:35:32 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 17 May 2007 21:35:32 +1200 Subject: Mock for EPEL In-Reply-To: <1179394217.11111.26.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> Message-ID: <464C21E4.1080605@nigelj.com> Tanguy Eric wrote: > Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : >> On 17.05.2007 11:00, Remi Collet wrote: >>> Tanguy Eric a ?crit : >>>> I would like to use mock on my fc6 to test build for epel 4 and 5 but i >>>> don't have any cfg file in /etc/mock about this. >>>> How can i do this ? >>> # rpm -qf /etc/mock/*epel* >>> mock-0.6.11-1.fc6 >>> >>> You probably should update your mock version. >>> >>> And use, p.e. mock -r fedora-4-ppc-epel >>> >>> You can create a fedora-5-ppc-epel using the model. >> Or use those attached to this mail -- I send them here past week already >> and we'll make sure they'll get integrated into mock soon. >> >> CU >> thl > Thanks but i seem to have problem with mirrorlist for epel4 : > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > init > clean > prep > This may take a while > not using ftp, http[s], or file for repos, skipping - PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - Index > of / > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - bgcolor=#3399FF text=#000000 cellSpacing=0 cellPadding=0 width="100%" > border=0 align="center"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
vAlign=top> > not using ftp, http[s], or file for repos, skipping - width="100%" border="0" cellspacing="0" cellpadding="0" height="66"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
colspan="1" rowspan="1" style="vertical-align: middle; text-align: left; > width: 63px"> > not using ftp, http[s], or file for repos, skipping - href="http://www.centos.org/"> src="/HEADER.images/centos_icon_60.png" alt="CentOS Icon" > border="0" /> > not using ftp, http[s], or file for repos, skipping - colspan="1" rowspan="1" style="vertical-align: middle; text-align: left; > "> > not using ftp, http[s], or file for repos, skipping - href="http://www.centos.org/"> src="/HEADER.images/centos_logo_45.png" alt="CentOS Logo" > border="0" /> > not using ftp, http[s], or file for repos, skipping - width="100%" align="right"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
> not using ftp, http[s], or file for repos, skipping -
> not using ftp, http[s], or file for repos, skipping - bgcolor="#e0d2e3" text=#5e5e5e cellSpacing=0 cellPadding=0 width="100%" > border=0 align="center"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
vAlign=top> > not using ftp, http[s], or file for repos, skipping - width="100%" border="0" cellspacing="0" cellpadding="0" height="25"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
valign=center> CentOS on the Web: href="http://www.centos.org/modules/tinycontent/index.php?id=16">Mailing > Lists | href="http://www.centos.org/modules/tinycontent/index.php?id=13">Mirror > List | href="http://www.centos.org/modules/tinycontent/index.php?id=8">IRC > | Forums | href="http://bugs.centos.org/">Bugs | href="http://www.centos.org/modules/tinycontent/index.php?id=23">Donate
> not using ftp, http[s], or file for repos, skipping -
> not using ftp, http[s], or file for repos, skipping - > > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
[ICO] href="?C=N;O=D">NameLast > modifiedSize href="?C=D;O=A">Description
colspan="5">
valign="top">[ ] href="TIME">TIME17-May-2007 09:10 align="right"> 11
valign="top">[DIR] href="centos-2/">centos-2/15-Sep-2005 23:34 > -
valign="top">[DIR] href="centos-3/">centos-3/06-Sep-2006 11:31 > -
valign="top">[DIR] href="centos-4/">centos-4/15-May-2007 20:47 > -
valign="top">[DIR] href="centos-5/">centos-5/15-Apr-2007 11:46 > -
valign="top">[DIR] href="centos/">centos/15-May-2007 11:47 > -
valign="top">[DIR] href="mirrorscripts/">mirrorscripts/ align="right">12-Apr-2006 08:42 -
valign="top">[TXT] href="server.id">server.id22-Sep-2004 15:24 > 0 centosc2
valign="top">[TXT] href="timestamp.txt">timestamp.txt17-May-2007 > 09:10 29
colspan="5">
> not using ftp, http[s], or file for repos, skipping - bgcolor="#e0d2e3" text=#5e5e5e cellSpacing=0 cellPadding=0 width="100%" > border=0 align="center"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
vAlign=top> > not using ftp, http[s], or file for repos, skipping - width="100%" border="0" cellspacing="0" cellpadding="0" height="25"> > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping - > not using ftp, http[s], or file for repos, skipping -
valign=center align=left> This CentOS server donated by: > Fasthosts Internet > Ltd valign=center align=right> I want to donate a server: href="mailto:donate at centos.org?subject=Server Donation">Contact > us
> not using ftp, http[s], or fiError: Cannot find a valid baseurl for > repo: core > le for repos, skipping -
> not using ftp, http[s], or file for repos, skipping - > > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > ending > done > I ended up by hard setting them to: [core] name=base baseurl=http://mirror.pacific.net.au/linux/CentOS/4.4/os/i386/ [update] name=updates baseurl=http://mirror.pacific.net.au/linux/CentOS/4.4/updates/i386/ [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ [extras] name=epel baseurl=http://ftp-stud.hs-esslingen.de/pub/epel/4/i386 [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ You might wish to set them to closer locations though. The HTML output is an oversight of CentOS I think though. N.J. From fedora at leemhuis.info Thu May 17 09:38:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 11:38:39 +0200 Subject: Mock for EPEL In-Reply-To: <1179394217.11111.26.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> Message-ID: <464C229F.2020503@leemhuis.info> On 17.05.2007 11:30, Tanguy Eric wrote: > Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : >> On 17.05.2007 11:00, Remi Collet wrote: >>> Tanguy Eric a ?crit : >>>> I would like to use mock on my fc6 to test build for epel 4 and 5 but i >>>> don't have any cfg file in /etc/mock about this. >>>> How can i do this ? >>> # rpm -qf /etc/mock/*epel* >>> mock-0.6.11-1.fc6 >>> >>> You probably should update your mock version. >>> >>> And use, p.e. mock -r fedora-4-ppc-epel >>> >>> You can create a fedora-5-ppc-epel using the model. >> Or use those attached to this mail -- I send them here past week already >> and we'll make sure they'll get integrated into mock soon. >> > Thanks but i seem to have problem with mirrorlist for epel4 : > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm Run: sed -i 's|mirror.centos.org|mirrorlist.centos.org|g' /etc/mock/*epel* Seems centos switched from mirror.centos.org to mirrorlist.centos.org Cu thl From eric.tanguy at univ-nantes.fr Thu May 17 09:51:07 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Thu, 17 May 2007 11:51:07 +0200 Subject: Mock for EPEL In-Reply-To: <464C229F.2020503@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> Message-ID: <1179395467.11111.28.camel@bureau.maison> Le jeudi 17 mai 2007 ? 11:38 +0200, Thorsten Leemhuis a ?crit : > > On 17.05.2007 11:30, Tanguy Eric wrote: > > Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : > >> On 17.05.2007 11:00, Remi Collet wrote: > >>> Tanguy Eric a ?crit : > >>>> I would like to use mock on my fc6 to test build for epel 4 and 5 but i > >>>> don't have any cfg file in /etc/mock about this. > >>>> How can i do this ? > >>> # rpm -qf /etc/mock/*epel* > >>> mock-0.6.11-1.fc6 > >>> > >>> You probably should update your mock version. > >>> > >>> And use, p.e. mock -r fedora-4-ppc-epel > >>> > >>> You can create a fedora-5-ppc-epel using the model. > >> Or use those attached to this mail -- I send them here past week already > >> and we'll make sure they'll get integrated into mock soon. > >> > > Thanks but i seem to have problem with mirrorlist for epel4 : > > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > > Run: > sed -i 's|mirror.centos.org|mirrorlist.centos.org|g' /etc/mock/*epel* > > Seems centos switched from mirror.centos.org to mirrorlist.centos.org > > Cu > thl Thanks it seems better now but i still have a problem : $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm init clean prep This may take a while Error: Cannot find a valid baseurl for repo: extras Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build ending done From fedora at leemhuis.info Thu May 17 10:24:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 12:24:23 +0200 Subject: Mock for EPEL In-Reply-To: <1179395467.11111.28.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> Message-ID: <464C2D57.9050903@leemhuis.info> On 17.05.2007 11:51, Tanguy Eric wrote: > Le jeudi 17 mai 2007 ? 11:38 +0200, Thorsten Leemhuis a ?crit : >> On 17.05.2007 11:30, Tanguy Eric wrote: >>> Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : >>>> On 17.05.2007 11:00, Remi Collet wrote: >>>>> Tanguy Eric a ?crit : > Thanks it seems better now but i still have a problem : > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > init > clean > prep > This may take a while > Error: Cannot find a valid baseurl for repo: extras > > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > ending > done Seem there is some problem with the mirrorlist creation on the Fedora servers -- http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 returns an empty list. Hardcode the repo from http://download.fedora.redhat.com/pub/epel/ directly for now -- for example use [extras] name=epel #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 baseurl=http://download.fedora.redhat.com/pub/epel/4/i386/ for EPEL4-i386 CU thl From fedora at leemhuis.info Thu May 17 10:27:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 12:27:50 +0200 Subject: Log from yesterdays (20070516) EPEL-SIG meeting Message-ID: <464C2E26.3060600@leemhuis.info> find below the log from yesterdays meeting -- I'll send a summary over the next few days. CU knurd 00:00 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00 < knurd> | Hi everybody; who's around? 00:00 * | nirik is here. 00:00 < knurd> | stahnma mentioned he might miss the meeting (or parts of it) 00:01 * | dgilmore is here 00:01 * | mmcgrath here 00:01 < mmcgrath> | yo 00:01 < knurd> | make 4 out of 6 00:02 < knurd> | makes 00:02 < knurd> | so let's start 00:02 --- | knurd has changed the topic to: EPEL Meeting -- repotags/interaction with 3rd party repos -- owner: all 00:02 < knurd> | hmmm 00:02 < knurd> | there was some discussion about this 00:02 < knurd> | I'd like to give it another week 00:02 < knurd> | I want to discuss cooperation with CentOS/z00dax a bit 00:03 < knurd> | and would like to leave the repotags issue open for that time 00:03 < knurd> | Fernando also did not reply to my last mail on the list yet 00:03 < knurd> | that okay for everybody? 00:03 < mmcgrath> | yep 00:03 < dgilmore> | thats fine with me 00:03 < knurd> | k, then I'll move on 00:03 < nirik> | sure. 00:03 --- | knurd has changed the topic to: EPEL Meeting -- vacant seat in the steering committee 00:04 < knurd> | similar here 00:04 < knurd> | I mailed the people thimm proposed 00:04 * | nirik hopes we can talk z00dax into joining... 00:04 < knurd> | four answered 00:04 < dgilmore> | do we have any other possible people? 00:04 < dgilmore> | nirik: that wouold be nice 00:04 < knurd> | dgilmore, we were talking if z00dax could join us 00:04 < nirik> | z00dax expressed interest, but doesn't want to sign the cla. 00:04 < knurd> | that's why I'd like to give this some more time, too 00:04 < dgilmore> | knurd: what was the responses? 00:04 < nirik> | not sure if he needs that for just providing input tho... 00:05 < dgilmore> | nirik: thats always been a bone of contention with him 00:05 < knurd> | from those four: a definite "no" or a "only if you don't somebody else" 00:05 < nirik> | yeah. 00:05 < knurd> | k; anything else regarding this topic? 00:06 * | knurd will skip "/topic EPEL Meeting -- Investigate single RHEL subscription for EPEL maintainers -- quaid" -- quaid not around 00:06 --- | knurd has changed the topic to: EPEL Meeting -- finish the wiki docs and remove the warnings 00:06 < knurd> | mether and quaid did some cleanups 00:06 < knurd> | after I did some 00:06 < knurd> | looks quite good now afaics 00:06 < knurd> | I'd say we remove those "not official yet" warning by next weeks meeting 00:07 < knurd> | as long as nobody yells until then 00:07 < mmcgrath> | +1 00:07 < knurd> | does that sounds sane? 00:07 < nirik> | I think we should wait until we have bodhi in place before we remove them and offically announce... 00:07 < dgilmore> | +1 00:07 < knurd> | nirik, well, a warning remains 00:07 < nirik> | I guess the wiki warning can be removed before that. 00:07 < mmcgrath> | I worry about when bodhi will actually be in place. 00:07 < knurd> | that EPEL still is not officially open/annource 00:07 < knurd> | d 00:07 < knurd> | but I'd say we can remove the other warnings 00:08 < nirik> | knurd: ok, then thats ok with me. 00:08 < nirik> | mmcgrath: me too. ;( 00:08 < mmcgrath> | I know lmacken is a very busy guy. 00:08 < knurd> | mmcgrath, any status update regarding bodhi? 00:08 < lmacken> | yes 00:08 < nirik> | speak of the lmacken. ;) 00:08 < mmcgrath> | lmacken is in the house :) 00:09 --> | wwoods (Will Woods) has joined #fedora-meeting 00:09 < lmacken> | it's still running on publictest2 and seems to be fairly stable.. there are still some minor issues that I need to fix, as well as a few very important items (F7 multilib being one of them) 00:09 < mmcgrath> | lmacken: would you be interested in using epel as a test deployment or would that cause more harm then good? 00:09 < knurd> | will it be used for F7 updates? 00:09 < lmacken> | mmcgrath: Hmm.. I'll have to think about that 00:09 < lmacken> | knurd: that's the plan 00:10 < lmacken> | https://hosted.fedoraproject.org/projects/bodhi/query?status=new&status=assigned&status=reopened&milestone=1.0 00:10 < knurd> | lmacken, someone from us should discuss the repolayout for EPEL with you somewhen 00:10 < lmacken> | for those interested in helping push this forward, that is the list of tasks that need to get done for 1.0 00:10 < knurd> | if that's possible at all or if we need to make adjustments 00:10 < nirik> | without it, epel doesn't have any testing repos, which is something that has to be fixed before we announce. 00:10 < knurd> | nirik, yes, sure 00:10 < lmacken> | knurd: yeah, a few minor adjustments need to be made.. i just haven't done them yet 00:10 < knurd> | nirik, I'll add "repolayout/bodhi/testing repo" to the schedule 00:11 < knurd> | lmacken, I'm sure we'll find a way to make everyone happy 00:11 < lmacken> | knurd: no doubt 00:11 < knurd> | I suppose getting bodhi in place for F7 is more important now 00:11 < knurd> | then we can look closer at bodhi for EPEL 00:11 < knurd> | but we should do that soon, too 00:11 < nirik> | lmacken: I can work on docs there if you can be around for answering my dumb questions... 00:12 < lmacken> | nirik: that would be awesome. 00:12 < lmacken> | i'm hoping to throw together a simple screencast at some point as well for pushing updates, since it is going to be a fairly trivial process 00:12 < nirik> | wiki ok for that? or just a text file or ? 00:12 < lmacken> | nirik: wiki is fine 00:12 < nirik> | ok, will whip up something and we can correct it. 00:13 < lmacken> | nirik: awesome, thanks 00:13 < knurd> | anything else regarding this topic? 00:13 < lmacken> | not from me.. i encourage people to play around on publictest2 and try and break stuff 00:13 < lmacken> | the updates-stage got wiped out last night though, so I have to re-initialize it in a few 00:14 * | knurd hasn't taken a single closer look at bodhi yet 00:14 * | knurd sill looking out for 36h days 00:14 < knurd> | s/sill/still/ 00:14 < knurd> | anyway, let's move on 00:14 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:14 < knurd> | anything else to discuss? 00:15 --> | Jeff_S (Jeff Sheltren) has joined #fedora-meeting 00:15 < knurd> | was the "start signal" mail on fedora-maintainers fine this way? 00:15 < nirik> | so, it looks like CentOS guys are going to push Xfce for their extras repo... so should I refrain from pushing it in epel? push it and try and keep it in sync? thoughts? 00:16 < knurd> | nirik, we should have it 00:16 < mmcgrath> | I'm under the opinion that stuff like that is up to the maintainers. 00:16 < knurd> | but we should talk with CentOS about some kind of cooperation maybe 00:16 < knurd> | mmcgrath, but we should not say "they have it, so we don't ship it" 00:16 < nirik> | yeah, I wish I knew who in centos was doing it... I just have word that it's happening via z00dax 00:17 < nirik> | also dag is going to do a munin package, which is one that I also want to do... will ponder on what I want to do. 00:17 < mmcgrath> | knurd: I'd say up to the maintainer to say "I'll use their spec file" or "I'll use my own". 00:17 < nirik> | on Xfce I might wait and see what their packages look like. 00:17 < knurd> | mmcgrath, k 00:17 < nirik> | their 4.2.1 packages were just my specs from fedora. 00:18 < nirik> | anyhow, just thought I would throw that out for comment. 00:18 < Jeff_S> | I would ask karan about sharing the spec somehow... 00:19 < Jeff_S> | especially if it is a rebuild of your FE package 00:19 < knurd> | we really need to find a way of cooperation so bugfixes find their way into CentOS, EPEL and Fedora 00:19 < nirik> | if they are very similar then I could see trying to keep them both in sync. 00:19 < knurd> | if all use the same kind of spec file 00:20 < knurd> | k, anything else? 00:20 < knurd> | otherwise I'd say we close this meeting for today and make it the fastest EPEL meeting ever 00:20 < Jeff_S> | sorry I was late! 00:20 < Jeff_S> | :) 00:20 < knurd> | Jeff_S, glad you're here 00:20 * | nirik has nothing else off hand. 00:20 < nirik> | oh, how about mock configs? 00:20 < knurd> | ohh 00:21 < nirik> | can we get those in the main mock package? 00:21 < nirik> | fixed and working. 00:21 < knurd> | somebody should open a bug about it 00:21 < knurd> | and submitt them to mock 00:21 < knurd> | anyone intersted? 00:21 * | quaid stumbles in late 00:21 --> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:21 < smooge> | Argh 00:21 < smooge> | srry 00:21 < Jeff_S> | or just email to the fedora-buildsys list.. no? 00:21 < knurd> | hi quaid, hi smooge 00:22 < dgilmore> | knurd: ill make sure they work 00:22 < Jeff_S> | that used to be the playground for mock/plague 00:22 < smooge> | I am late.. my apologies 00:22 < dgilmore> | Jeff_S: still is 00:22 < knurd> | dgilmore, CentOS 5 ppc is not relased yet 00:22 < dgilmore> | bad smooge ;) 00:22 < dgilmore> | knurd: i know 00:22 < knurd> | dgilmore, so we should not include those yet 00:22 < knurd> | dgilmore, and z00day mentioned something about two "streams" 00:22 < nirik> | well, it would be nice if the ones in the mock package for fc5/fc6/devel/epel all got updated to work with epel 4/5 00:22 < knurd> | nirik, +1 00:23 < dgilmore> | I will make sure that they work for epel 00:23 < nirik> | dgilmore: cool. thanks. 00:23 < knurd> | quaid, there is "Investigate single RHEL subscription for EPEL maintainers -- quaid" on the schedule 00:23 < knurd> | is that sill valid? 00:23 < knurd> | still 00:23 < Jeff_S> | yes, I am interested in that - thought I missed it 00:23 < quaid> | about the FAQ and other EPEL pages ... I have a priority item to go over all of them, because they are a bit, uh, linguistically challenged in a few places, and somewhat confusing; I want to do the reorg of the FAQ as per what knurd suggested (packagers, users), and so forth; I can then remove the "draft" tag at that point 00:24 < knurd> | quaid, sounds fine to me 00:24 < knurd> | quaid, but we should try to get it finished this months IMHO 00:24 < knurd> | I want the wiki finished and the warnings gone :) 00:25 < smooge> | Will we be answering who the EPEL customers are thought to be to distinguish it from other customer bases? 00:25 < knurd> | smooge, I just replied to your mail 00:25 * | quaid finished catching up on the buffer 00:25 < knurd> | smooge, I'd say we should continue to discuss this on the list 00:25 < knurd> | smooge, and yes, maybe we should write something up then 00:25 < knurd> | s/then/sooner or later/ 00:25 < quaid> | knurd: yes, finishing wiki by ... end of this week(end) ... is my goal 00:26 < knurd> | quaid, even better :) 00:26 < quaid> | as for the RHEL subscriptions, I haven't gotten too far with that ... still looking for the right person 00:26 < knurd> | quaid, k; I'll leave it on the schedule then? 00:26 < quaid> | did I ask mmcgrath who you got subs from for Fedora? 00:26 < quaid> | knurd: yeah, let's keep at it 00:26 < mmcgrath> | quaid: I don't remember :) 00:26 < quaid> | maybe Fedora can just "purchase" a few hunder more subs and give them out via RHN to EPEl maintainers 00:27 < quaid> | mmcgrath: Fedora has its own RHN management group now, though, right? You went through CustSvc to get that 00:27 < mmcgrath> | I believe so, yes. 00:27 < mmcgrath> | But I have pretty specific rules regarding our subscriptions and the binary RPMs. 00:27 < quaid> | ok, let's look at what it would take to up the entitlements by a bit to support EPEl 00:28 < quaid> | oh, sure;esp. bin rpms, that's why we want official subs for EPEL folks 00:28 < quaid> | so its all above board and we can be clear, "These EPEL packages were tested and built on 100% RHEL" 00:28 < knurd> | quaid, maybe test machines (xen guests that can be reverted to a certain state after being used) would be helpfull already 00:29 < Jeff_S> | Of course it would be nice to test them on CentOS as well, as that is a large EL user base (like me) :) 00:29 < knurd> | but I'm not sure what is easier: hand out some RHEL subscriptions to EPEL people or set up semi-public test.machines 00:29 * | nirik is also a very heavy CentOS user. 00:29 * | Jeff_S only 150 lbs. 00:29 < quaid> | Jeff_S: in fact, we could have a multi-OS build env like we have a multi-arch 00:29 * | knurd uses centos as well 00:29 * | dgilmore uses both RHEL and CentOS 00:30 * | mmcgrath thinks CentOS is easier to use. 00:30 < knurd> | mmcgrath, likely 00:30 * | dgilmore is 265lbs 00:30 < quaid> | knurd: maintainers need to be able to build offline, too 00:30 < Jeff_S> | I think CentOS is easier to use, but I would love to be able to build/test packages on RHEL as well 00:30 < quaid> | but I like the idea of a semi-public build system, too 00:30 < knurd> | quaid, yeah. but centos should be fine for them afaics 00:30 < knurd> | most of the time 00:30 < quaid> | mmcgrath: sure, we could just tell all to use CentOS, and to maintainers, its probably all the same 00:30 < quaid> | but for users ... 00:31 < smooge> | With the key requirements for RHEL-5, CentOS has been much easi to use 00:31 < mmcgrath> | quaid: well lets see how far you can get with subscriptions. 00:31 < quaid> | well, there is some value in knowing it was built on their particular env; for EPEL I think the publicity is good; and it's kind of a nice perq for being a maintainer 00:31 < quaid> | yep 00:31 < mmcgrath> | if that fails we can plan on using xen though our xen resources are very low right now. 00:31 < mmcgrath> | some projects are already on hold :-/ 00:32 < knurd> | k, anything else? 00:32 < mmcgrath> | nothing here. 00:32 * | knurd will close the meeting in 60 if nothing new shows up 00:32 * | knurd will close the meeting in 45 00:33 < smooge> | Did we go over build schedule? 00:33 * | knurd will close the meeting in 30 00:33 < knurd> | smooge, what do you mean by "build schedule"? 00:33 < smooge> | As in timeline for getting x86,x86_64 out the door? 00:33 < smooge> | for at least a set of beta-testers? 00:33 < nirik> | smooge: the repos are already available. 00:33 < nirik> | for testing. 00:33 < smooge> | if so I will read in the notes 00:33 < knurd> | smooge, we did not discuss this 00:34 < nirik> | http://download.fedora.redhat.com/pub/epel/ 00:34 < smooge> | its ok if its for next meeting 00:34 < knurd> | smooge, but you have a point; maybe we should abnouce some kind of "beta" soon 00:34 < knurd> | I'll add it to the schedule for the next meeting 00:34 < smooge> | nirik, most of the posts to the lists have not mentioned this but have said real soon 00:34 < knurd> | smooge, feel free to bring the topic up on the list 00:34 < smooge> | that was why i was asking 00:34 * | nirik would like to see testing in place before too many people start using and getting used to it not being there. 00:35 < knurd> | nirik, yeah, you have a point 00:35 * | knurd will close the meeting in 30 00:35 < nirik> | perhaps we could manually move all the current release items into updates-testing? then announce a beta with the updates-testing repo? 00:35 < knurd> | nirik, yeah, but we should know if the final layout really is possible with bodhi first 00:36 < nirik> | true 00:36 * | knurd will close the meeting in 20 00:36 < knurd> | anything else? 00:36 * | knurd will close the meeting in 10 00:36 < knurd> | -- MARK -- Meeting end From Matt_Domsch at Dell.com Thu May 17 12:15:29 2007 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Thu, 17 May 2007 07:15:29 -0500 Subject: Mock for EPEL References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> Message-ID: I fixed the mirrorlist for EPEL now. Somehow some stale files got loaded into mirrormanager's directory on the app server which confused it greatly... Everything, not just EPEL, was broken for a bit. -- Matt Domsch Software Architect Dell Linux Solutions www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com -----Original Message----- From: Thorsten Leemhuis [mailto:fedora at leemhuis.info] Sent: Thu 5/17/2007 5:24 AM To: EPEL development disccusion Subject: Re: Mock for EPEL On 17.05.2007 11:51, Tanguy Eric wrote: > Le jeudi 17 mai 2007 ? 11:38 +0200, Thorsten Leemhuis a ?crit : >> On 17.05.2007 11:30, Tanguy Eric wrote: >>> Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : >>>> On 17.05.2007 11:00, Remi Collet wrote: >>>>> Tanguy Eric a ?crit : > Thanks it seems better now but i still have a problem : > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > init > clean > prep > This may take a while > Error: Cannot find a valid baseurl for repo: extras > > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > ending > done Seem there is some problem with the mirrorlist creation on the Fedora servers -- http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 returns an empty list. Hardcode the repo from http://download.fedora.redhat.com/pub/epel/ directly for now -- for example use [extras] name=epel #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 baseurl=http://download.fedora.redhat.com/pub/epel/4/i386/ for EPEL4-i386 CU thl From fedora at leemhuis.info Thu May 17 12:27:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 14:27:02 +0200 Subject: Mock for EPEL In-Reply-To: <464C2D57.9050903@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> Message-ID: <464C4A16.4000800@leemhuis.info> On 17.05.2007 12:24, Thorsten Leemhuis wrote: > [...] > Seem there is some problem with the mirrorlist creation on the Fedora > servers -- > http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 > returns an empty list. Fixed now thx to our sysadmins. Cu thl From fedora at leemhuis.info Thu May 17 12:30:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 14:30:22 +0200 Subject: Mock for EPEL In-Reply-To: <464C4A16.4000800@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <464C4A16.4000800@leemhuis.info> Message-ID: <464C4ADE.2090602@leemhuis.info> On 17.05.2007 14:27, Thorsten Leemhuis wrote: > > On 17.05.2007 12:24, Thorsten Leemhuis wrote: >> [...] >> Seem there is some problem with the mirrorlist creation on the Fedora >> servers -- >> http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 >> returns an empty list. > Fixed now thx to our sysadmins. Just after sending this mail fetchmail retrieved the one from Matt. Thx again Matt! Cu thl From mastahnke at gmail.com Thu May 17 14:50:00 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 17 May 2007 09:50:00 -0500 Subject: YUM for RHEL 4 In-Reply-To: <20070517062759.GA16994@humbolt.us.dell.com> References: <464BECE2.1080601@FamilleCollet.com> <20070517062759.GA16994@humbolt.us.dell.com> Message-ID: <7874d9dd0705170750n491e4d7csff1c63ab966a9499@mail.gmail.com> On 5/17/07, Michael E Brown wrote: > On Thu, May 17, 2007 at 07:49:22AM +0200, Remi Collet wrote: > > A stupid question, i probably miss something. > > > > CentOS 4 provides yum 2.4 > > > > RHEL 4 doesn't provides yum, but it is available on a very > > famous/usefull/high quality third party repository. > > > > How RHEL 4 users will use our new EPEL repository without yum ? > > > > Of course, if we want good collaboration, we must use the same version > > than dag and centos. > > Up2date can be trivially configured to pull packages from yum > repositories. > > Red Hat just released RHEL 4.5 with some important fixes to up2date for > bugs I found a while back. ($releasever improperly hardcoded to 3... > hmmm, testing anybody?) > > For the Dell yum repositories, I have the 'dell-repository' RPM, which > will automatically add both yum and up2date configs. The epel-release package does the same. > -- > Michael > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From Michael_E_Brown at dell.com Thu May 17 15:11:14 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 17 May 2007 10:11:14 -0500 Subject: YUM for RHEL 4 In-Reply-To: <7874d9dd0705170750n491e4d7csff1c63ab966a9499@mail.gmail.com> References: <464BECE2.1080601@FamilleCollet.com> <20070517062759.GA16994@humbolt.us.dell.com> <7874d9dd0705170750n491e4d7csff1c63ab966a9499@mail.gmail.com> Message-ID: <20070517151113.GA5006@humbolt.us.dell.com> On Thu, May 17, 2007 at 09:50:00AM -0500, Michael Stahnke wrote: > >For the Dell yum repositories, I have the 'dell-repository' RPM, which > >will automatically add both yum and up2date configs. > The epel-release package does the same. Awesome. Another place I can steal^H^H^H^Hborrow code from.... I wonder if what you are doing is better than what I do. /me checks epel-release -- Michael From buildsys at fedoraproject.org Fri May 18 03:18:28 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 17 May 2007 23:18:28 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-17 Message-ID: <20070518031828.6D004152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 26 NEW drgeo-1.1.0-11.el5 : Interactive educational geometry software NEW drgeo-doc-1.6-8.el5 : Html documentation for drgeo NEW freehdl-0.0.4-2.el5 : GPLed free VHDL NEW gperiodic-2.0.8-7.el5 : Program for browsing the periodic table NEW incron-0.5.5-1.el5 : Inotify cron system NEW ircd-hybrid-7.2.3-1.el5 : Internet Relay Chat Server NEW libiptcdata-1.0.2-1.el5 : IPTC tag library NEW libupnp-1.4.6-1.el5 : Universal Plug and Play (UPnP) SDK NEW pdns-recursor-3.1.4-4.el5 : Modern, advanced and high performance recursing/non authoritative nameserver NEW perl-Apache-DBI-1.06-1.el5 : Persistent database connections with Apache/mod_perl NEW perl-Boulder-1.30-3.el5 : An API for hierarchical tag/value structures NEW perl-HTML-Table-2.05-1.el5 : Create HTML tables using simple interface NEW perl-Net-IP-CMatch-0.02-4.el5 : Efficiently match IP addresses against IP ranges with C NEW perl-Net-Patricia-1.014-3.el5 : Patricia Trie perl module for fast IP address lookups NEW perl-String-Approx-3.26-1.el5 : Perl extension for approximate matching (fuzzy matching) NEW perl-XML-DOM-1.44-2.el5 : DOM extension to XML::Parser NEW perl-XML-RegExp-0.03-2.el5 : Regular expressions for XML tokens NEW php-pear-DB-1.7.6-7.el5 : PEAR: Database Abstraction Layer NEW php-pear-Log-1.9.10-1.el5 : Abstracted logging facility for PHP NEW python-docutils-0.4-3.el5 : A system for processing plaintext documentation NEW python-numarray-1.5.2-1.el5 : Python array manipulation and computational library NEW qucs-0.0.11-1.el5 : Circuit simulator NEW ruby-mysql-2.7.3-1.el5 : A Ruby interface to MySQL NEW specto-0.2.0-3.el5 : An desktop application that will watch configurable events NEW ushare-0.9.10-1.el5 : UPnP (TM) A/V Media Server NEW yum-arch-2.2.2-2.el5 : Extract headers from rpm in a old yum repository Packages built and released for Fedora EPEL 4: 19 NEW drgeo-doc-1.6-5.el4 : Html documentation for drgeo NEW freehdl-0.0.3-1.el4 : GPLed free VHDL NEW gperiodic-2.0.8-2.el4 : Program for browsing the periodic table NEW ircd-hybrid-7.2.2-1.el4 : Internet Relay Chat Server NEW libupnp-1.4.1-1.el4 : Universal Plug and Play (UPnP) SDK NEW pdns-recursor-3.1.4-4.el4 : Modern, advanced and high performance recursing/non authoritative nameserver NEW perl-Apache-DBI-1.06-1.el4 : Persistent database connections with Apache/mod_perl NEW perl-Boulder-1.30-3.el4 : An API for hierarchical tag/value structures NEW perl-HTML-Table-2.05-1.el4 : Create HTML tables using simple interface NEW perl-Net-IP-CMatch-0.02-4.el4 : Efficiently match IP addresses against IP ranges with C NEW perl-Net-Patricia-1.014-3.el4 : Patricia Trie perl module for fast IP address lookups NEW perl-String-Approx-3.26-1.el4 : Perl extension for approximate matching (fuzzy matching) NEW perl-XML-DOM-1.44-2.el4 : DOM extension to XML::Parser NEW perl-XML-RegExp-0.03-2.el4 : Regular expressions for XML tokens NEW Pound-2.3-1.el4 : Reverse proxy and load balancer NEW python-numarray-1.5.2-1.el4 : Python array manipulation and computational library NEW qucs-0.0.10-1.el4 : Circuit simulator NEW ruby-mysql-2.7.3-1.el4 : A Ruby interface to MySQL NEW specto-0.2.0-3.el4 : An desktop application that will watch configurable events Changes in Fedora EPEL 5: drgeo-1.1.0-11.el5 ------------------ * Mon Aug 28 2006 Eric Tanguy - 1.1.0-11 - Rebuild for Fedora Extras 6 drgeo-doc-1.6-8.el5 ------------------- * Mon Aug 28 2006 Eric Tanguy - 1.6-8 - Rebuild for Fedora Extras 6 freehdl-0.0.4-2.el5 ------------------- * Thu Apr 19 2007 Eric Tanguy 0.0.4-2 - Add texinfo to BuildRequires gperiodic-2.0.8-7.el5 --------------------- * Thu Nov 09 2006 Eric Tanguy - 2.0.8-7 - Correct information for "Bh", Bohrium incron-0.5.5-1.el5 ------------------ * Tue Mar 13 2007 0.5.5-1 - Sync with upstream ircd-hybrid-7.2.3-1.el5 ----------------------- * Mon Aug 28 2006 Eric Tanguy - 7.2.3-1 - Update de 7.2.3 libiptcdata-1.0.2-1.el5 ----------------------- * Tue May 15 2007 David Moore 1.0.2-1 - New upstream version libupnp-1.4.6-1.el5 ------------------- * Tue May 01 2007 Eric Tanguy - 1.4.6-1 - Update to version 1.4.6 * Sat Apr 21 2007 Eric Tanguy - 1.4.4-1 - Update to version 1.4.4 pdns-recursor-3.1.4-4.el5 ------------------------- * Sat Jan 27 2007 3.1.4-4 - Now really fix the description in init script perl-Apache-DBI-1.06-1.el5 -------------------------- * Sun Mar 25 2007 Remi Collet 1.06-1 - update to 1.06 perl-Boulder-1.30-3.el5 ----------------------- * Thu Sep 07 2006 Orion Poplawski 1.30-3 - Rebuild for FC6 perl-HTML-Table-2.05-1.el5 -------------------------- * Thu May 17 2007 Orion Poplawski 2.05-1 - Update to 2.05 perl-Net-IP-CMatch-0.02-4.el5 ----------------------------- * Tue Aug 29 2006 - Orion Poplawski - 0.02-4 - Rebuild for FC6 perl-Net-Patricia-1.014-3.el5 ----------------------------- * Tue Aug 29 2006 - Orion Poplawski - 1.014-3 - Rebuild for FC6 perl-String-Approx-3.26-1.el5 ----------------------------- * Mon Nov 20 2006 Orion Poplawski 3.26-1 - Specfile autogenerated by cpanspec 1.69.1. perl-XML-DOM-1.44-2.el5 ----------------------- * Thu Jun 29 2006 Orion Poplawski - 1.44-2 - Bump for new perl version (#196667) perl-XML-RegExp-0.03-2.el5 -------------------------- * Thu Jun 29 2006 Orion Poplawski - 0.03-2 - Bump for new perl version (#196668) php-pear-DB-1.7.6-7.el5 ----------------------- * Sun Sep 10 2006 Tim Jackson 1.7.6-7 - Update spec to new conventions (#198706) php-pear-Log-1.9.10-1.el5 ------------------------- * Mon Feb 12 2007 Remi Collet 1.9.10-1 - update to 1.9.10 - All tests succeed with php-5.2.x : http://pear.php.net/bugs/bug.php?id=9023 python-docutils-0.4-3.el5 ------------------------- * Tue Aug 29 2006 Toshio Kuratomi 0.4-3 - Bump for FC6 rebuild. - Remove python byte compilation as this is handled automatically in FC4+. - No longer %ghost .pyo files. python-numarray-1.5.2-1.el5 --------------------------- * Wed Sep 06 2006 - Orion Poplawski - 1.5.2-1 - Update to 1.5.2 - No longer ghost .pyo files qucs-0.0.11-1.el5 ----------------- * Sun Mar 18 2007 Eric Tanguy - 0.0.11-1 - Update to 0.0.11 ruby-mysql-2.7.3-1.el5 ---------------------- * Thu May 17 2007 Orion Poplawski - 2.7.3-1 - Update to 2.7.3 specto-0.2.0-3.el5 ------------------ * Tue Mar 06 2007 Xavier Lamien - 0.2.0-3 - Removed 'gnome-python2' as redundant require. - Fixed default doc directory and added VERSION file in it. ushare-0.9.10-1.el5 ------------------- * Mon Feb 26 2007 Eric Tanguy - 0.9.10-1 - Update to 0.9.10 yum-arch-2.2.2-2.el5 -------------------- * Sun Feb 18 2007 Remi Collet - 2.2.2-2 - from package review (#229123) own /usr/share/yum-arch del shellbang in libs Changes in Fedora EPEL 4: drgeo-doc-1.6-5.el4 ------------------- * Wed Nov 02 2005 Eric Tanguy - 1.6-5 - Own of /usr/share/drgeo/help freehdl-0.0.3-1.el4 ------------------- * Fri Sep 01 2006 Eric Tanguy 0.0.3-1 - Update to 0.0.3 gperiodic-2.0.8-2.el4 --------------------- * Mon Oct 24 2005 Eric Tanguy - 2.0.8-2 - Applied patch file : https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120301 ircd-hybrid-7.2.2-1.el4 ----------------------- * Mon Jul 17 2006 Eric Tanguy - 7.2.2-1 - Update de 7.2.2 libupnp-1.4.1-1.el4 ------------------- * Wed Jul 05 2006 Eric Tanguy - 1.4.1-1 - Update to version 1.4.1 pdns-recursor-3.1.4-4.el4 ------------------------- * Sat Jan 27 2007 3.1.4-4 - Now really fix the description in init script perl-Apache-DBI-1.06-1.el4 -------------------------- * Sun Mar 25 2007 Remi Collet 1.06-1 - update to 1.06 perl-Boulder-1.30-3.el4 ----------------------- * Thu Sep 07 2006 Orion Poplawski 1.30-3 - Rebuild for FC6 perl-HTML-Table-2.05-1.el4 -------------------------- * Thu May 17 2007 Orion Poplawski 2.05-1 - Update to 2.05 perl-Net-IP-CMatch-0.02-4.el4 ----------------------------- * Tue Aug 29 2006 - Orion Poplawski - 0.02-4 - Rebuild for FC6 perl-Net-Patricia-1.014-3.el4 ----------------------------- * Tue Aug 29 2006 - Orion Poplawski - 1.014-3 - Rebuild for FC6 perl-String-Approx-3.26-1.el4 ----------------------------- * Mon Nov 20 2006 Orion Poplawski 3.26-1 - Specfile autogenerated by cpanspec 1.69.1. perl-XML-DOM-1.44-2.el4 ----------------------- * Thu Jun 29 2006 Orion Poplawski - 1.44-2 - Bump for new perl version (#196667) perl-XML-RegExp-0.03-2.el4 -------------------------- * Thu Jun 29 2006 Orion Poplawski - 0.03-2 - Bump for new perl version (#196668) Pound-2.3-1.el4 --------------- * Wed Apr 11 2007 Ruben Kerkhof 2.3-1 - Update to 2.3 python-numarray-1.5.2-1.el4 --------------------------- * Wed Sep 06 2006 - Orion Poplawski - 1.5.2-1 - Update to 1.5.2 - No longer ghost .pyo files qucs-0.0.10-1.el4 ----------------- * Fri Sep 01 2006 Eric Tanguy - 0.0.10-1 - Update to 0.0.10 ruby-mysql-2.7.3-1.el4 ---------------------- * Thu May 17 2007 Orion Poplawski - 2.7.3-1 - Update to 2.7.3 specto-0.2.0-3.el4 ------------------ * Tue Mar 06 2007 Xavier Lamien - 0.2.0-3 - Removed 'gnome-python2' as redundant require. - Fixed default doc directory and added VERSION file in it. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri May 18 04:34:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 18 May 2007 00:34:38 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-18 Message-ID: <20070518043438.859E2152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 4: 29 (!) bugzilla-2.22.2-1.el4 : INVALID rebuild, not published! (!) crack-5.0a-2.el4 : INVALID rebuild, not published! (!) DMitry-1.3a-2.el4 : INVALID rebuild, not published! drgeo-doc-1.6-5.el4 freehdl-0.0.3-1.el4 gperiodic-2.0.8-2.el4 (!) ike-scan-1.9-3.el4 : INVALID rebuild, not published! ircd-hybrid-7.2.2-1.el4 libupnp-1.4.1-1.el4 (!) nbtscan-1.5.1-2.el4 : INVALID rebuild, not published! (!) ocaml-3.09.2-1.el4 : INVALID rebuild, not published! pdns-recursor-3.1.4-4.el4 perl-Apache-DBI-1.06-1.el4 perl-Boulder-1.30-3.el4 perl-HTML-Table-2.05-1.el4 (!) perl-libwhisker2-2.4-2.el4 : INVALID rebuild, not published! perl-Net-IP-CMatch-0.02-4.el4 perl-Net-Patricia-1.014-3.el4 perl-String-Approx-3.26-1.el4 perl-XML-DOM-1.44-2.el4 perl-XML-RegExp-0.03-2.el4 Pound-2.3-1.el4 (!) python-krbV-1.0.13-5.el4 : INVALID rebuild, not published! python-numarray-1.5.2-1.el4 qucs-0.0.10-1.el4 ruby-mysql-2.7.3-1.el4 (!) scponly-4.6-5.el4 : INVALID rebuild, not published! specto-0.2.0-3.el4 (!) windowlab-1.34-6.el4 : INVALID rebuild, not published! Changes in Fedora EPEL 4: bugzilla-2.22.2-1.el4 --------------------- * Tue Feb 20 2007 John Berninger - 2.22.2-1 - Update to 2.22.2 - bz 229163 crack-5.0a-2.el4 ---------------- * Thu May 10 2007 Christian Iseli 5.0a-2 - Fix #239575: crack uses obsolete sort option syntax DMitry-1.3a-2.el4 ----------------- * Sat May 12 2007 Sindre Pedersen Bj?rdal - 1.3a-2 - Bump release for rebuild drgeo-doc-1.6-5.el4 ------------------- * Wed Nov 02 2005 Eric Tanguy - 1.6-5 - Own of /usr/share/drgeo/help freehdl-0.0.3-1.el4 ------------------- * Fri Sep 01 2006 Eric Tanguy 0.0.3-1 - Update to 0.0.3 gperiodic-2.0.8-2.el4 --------------------- * Mon Oct 24 2005 Eric Tanguy - 2.0.8-2 - Applied patch file : https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120301 ike-scan-1.9-3.el4 ------------------ * Sun May 13 2007 Sindre Pedersen Bj?rdal - 1.9-3 - bump release for rebuild ircd-hybrid-7.2.2-1.el4 ----------------------- * Mon Jul 17 2006 Eric Tanguy - 7.2.2-1 - Update de 7.2.2 libupnp-1.4.1-1.el4 ------------------- * Wed Jul 05 2006 Eric Tanguy - 1.4.1-1 - Update to version 1.4.1 nbtscan-1.5.1-2.el4 ------------------- * Sat May 12 2007 Sindre Pedersen Bj?rdal - 1.5.1-2 - Bump version for rebuild ocaml-3.09.2-1.el4 ------------------ * Sun Apr 30 2006 Gerard Milmeister - 3.09.2-1 - new version 3.09.2 pdns-recursor-3.1.4-4.el4 ------------------------- * Sat Jan 27 2007 3.1.4-4 - Now really fix the description in init script perl-Apache-DBI-1.06-1.el4 -------------------------- * Sun Mar 25 2007 Remi Collet 1.06-1 - update to 1.06 perl-Boulder-1.30-3.el4 ----------------------- * Thu Sep 07 2006 Orion Poplawski 1.30-3 - Rebuild for FC6 perl-HTML-Table-2.05-1.el4 -------------------------- * Thu May 17 2007 Orion Poplawski 2.05-1 - Update to 2.05 perl-libwhisker2-2.4-2.el4 -------------------------- * Tue May 08 2007 Sindre Pedersen Bj?rdal - 2.4-2 - Fix typo in Source0 url - Update lw1bridge patch to not include License info - Add explicit version to Provides and Obsoletes - Added tests, commented out - Cleaned up BuildRequires and Requires perl-Net-IP-CMatch-0.02-4.el4 ----------------------------- * Tue Aug 29 2006 - Orion Poplawski - 0.02-4 - Rebuild for FC6 perl-Net-Patricia-1.014-3.el4 ----------------------------- * Tue Aug 29 2006 - Orion Poplawski - 1.014-3 - Rebuild for FC6 perl-String-Approx-3.26-1.el4 ----------------------------- * Mon Nov 20 2006 Orion Poplawski 3.26-1 - Specfile autogenerated by cpanspec 1.69.1. perl-XML-DOM-1.44-2.el4 ----------------------- * Thu Jun 29 2006 Orion Poplawski - 1.44-2 - Bump for new perl version (#196667) perl-XML-RegExp-0.03-2.el4 -------------------------- * Thu Jun 29 2006 Orion Poplawski - 0.03-2 - Bump for new perl version (#196668) Pound-2.3-1.el4 --------------- * Wed Apr 11 2007 Ruben Kerkhof 2.3-1 - Update to 2.3 python-krbV-1.0.13-5.el4 ------------------------ * Mon Dec 11 2006 Mike Bonnet - 1.0.13-5 - remove obsolete python-abi Requires: python-numarray-1.5.2-1.el4 --------------------------- * Wed Sep 06 2006 - Orion Poplawski - 1.5.2-1 - Update to 1.5.2 - No longer ghost .pyo files qucs-0.0.10-1.el4 ----------------- * Fri Sep 01 2006 Eric Tanguy - 0.0.10-1 - Update to 0.0.10 ruby-mysql-2.7.3-1.el4 ---------------------- * Thu May 17 2007 Orion Poplawski - 2.7.3-1 - Update to 2.7.3 scponly-4.6-5.el4 ----------------- * Tue Jun 27 2006 Toshio Kuratomi - 4.6-5 - Add BR: openssh-server so sftp-server is present. - Make source files nonexecutable so they are nonexecutable in debuginfo. - Mark the scponly configuration files as %config. specto-0.2.0-3.el4 ------------------ * Tue Mar 06 2007 Xavier Lamien - 0.2.0-3 - Removed 'gnome-python2' as redundant require. - Fixed default doc directory and added VERSION file in it. windowlab-1.34-6.el4 -------------------- * Wed May 16 2007 Nigel Jones 1.34-6 - Fix x86_64 issue for library search dir For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dennis at ausil.us Fri May 18 04:36:17 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 17 May 2007 23:36:17 -0500 Subject: Fedora EPEL Package Build Report 2007-05-18 In-Reply-To: <20070518043438.859E2152131@buildsys.fedoraproject.org> References: <20070518043438.859E2152131@buildsys.fedoraproject.org> Message-ID: <200705172336.22560.dennis@ausil.us> Once upon a time Thursday 17 May 2007, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora EPEL 4: 29 So i made a mistake and had to repush some packages. Sorry for the noise Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eric.tanguy at univ-nantes.fr Fri May 18 07:31:46 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 18 May 2007 09:31:46 +0200 Subject: Mock for EPEL In-Reply-To: <464C2D57.9050903@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> Message-ID: <1179473506.11111.34.camel@bureau.maison> Le jeudi 17 mai 2007 ? 12:24 +0200, Thorsten Leemhuis a ?crit : > > On 17.05.2007 11:51, Tanguy Eric wrote: > > Le jeudi 17 mai 2007 ? 11:38 +0200, Thorsten Leemhuis a ?crit : > >> On 17.05.2007 11:30, Tanguy Eric wrote: > >>> Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : > >>>> On 17.05.2007 11:00, Remi Collet wrote: > >>>>> Tanguy Eric a ?crit : > > Thanks it seems better now but i still have a problem : > > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > > init > > clean > > prep > > This may take a while > > Error: Cannot find a valid baseurl for repo: extras > > > > Error performing yum command: /usr/sbin/mock-helper yum > > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > > ending > > done > > Seem there is some problem with the mirrorlist creation on the Fedora > servers -- > http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 > returns an empty list. > > Hardcode the repo from http://download.fedora.redhat.com/pub/epel/ > directly for now -- for example use > > [extras] > name=epel > #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 > baseurl=http://download.fedora.redhat.com/pub/epel/4/i386/ > > for EPEL4-i386 > One more problem this morning : $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm init clean prep This may take a while http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Fri, 18 May 2007 07:30:34 GMT Server: Apache/2.0.52 Content-Length: 342 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] No more mirrors to try. Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build ending done Eric From nando at ccrma.Stanford.EDU Fri May 18 16:50:09 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Fri, 18 May 2007 09:50:09 -0700 Subject: EPEL report 2007, week 19 In-Reply-To: <4646C6F7.4020607@leemhuis.info> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> Message-ID: <1179507009.10500.7.camel@cmn15.stanford.edu> [sorry for the delay, maybe too late but here it goes anyway - was way too busy then and I'm now in the middle of a trip visiting family so email access is sporadic...] On Sun, 2007-05-13 at 10:06 +0200, Thorsten Leemhuis wrote: > Fernando Lopez-Lezcano schrieb: > > On Sat, 2007-05-12 at 15:10 +0200, Thorsten Leemhuis wrote: > >> Josh Boyer schrieb: > >>>> * repotags -- some discussion in the meeting again. It looks like it > >>>> will we'll continue without repotags (final decision probably in next > >>>> weeks meeting, after this summary has been posted and discussed). If you > >>>> want repotags please *speak up now* > > I do. But maybe you are just asking for "I do"'s from list participants > > that do not have a third party repo? > > Actually I'm interested in opnions from everyone; but I'm especially > interested in opnions from Fedora/EPEL contributos. > > > Rationale for support has been already hashed to death in many threads. > > And others that don't see a sense or benefit in repotags (or even think > they do harm) have expressed their opinion as well. Yes, of course, I did not mean only supporting opinions had been expressed, that would make this a no-brainer :-) My personal, biased and most probably incomplete reading of the opposing opinions include "I wish this would just go away"[*], "this introduces problems in ordering of packages between repositories", "we are being forced to do this and we don't want to", "it is a bad solution to the problem", "it would be a problem to set this up in the epel build system" and "political problems in consistence between epel and the rest of fedora". I think most if not all the technical points have had reasonable technical responses from the proponents (and long time users) of repotags. [*] I'm _not_ trying to flame, I actually read this in one of the irc sessions and I think several emails as well. > >>>> and *help* to find a technical > >>>> solution that is not only fine for the EPEL Steering Committee, but also > >>>> acceptable for the Fedora Packaging Committee and FESCo -- from > >>>> discussions on list and on IRC it looks like that some members of those > >>>> groups tend to be against using repotags (see this weeks FESCo meeting > >>>> for example) or want to see something cooperation statements signed by > >>>> EPEL and 3rd party repos before they are willing to accept repotags. > >>> Just some clarification. Yes, FESCo overall didn't see a good reason to > >>> use repotags. If EPEL chooses to do so, FESCo won't stand in the way. > >> FYI: I was a bit against repotags in the past, but my position these > >> days after all this discussions is similar. > >> Or, to be more verbose: If someone works out the details on how to > >> realize repotags in Fedora then (depending on how the proposal looks > >> like) I'll likely abstain from a vote or might even support to use > >> repotags, as long as a simple "cp FC-6/foo.spec EL-5/" remains possible. > >> But I don't have the energy to work out the details. Anyone willing to > >> work them out? > > > > I presume this is internal help? (meaning how to tweak the build system > > to support them transparently without any impact to the spec files > > themselves?) > > No, more meaning: Find a technical and political solution that is > acceptable for EPEL SIG and the Fedora Packaging Committee (and FESCo, > if it wants to ). > > And let me warn you: there seems to be a opposition against repotags on > that way from what I can see, so this process might take weeks and > likely lots of discussions and mails. There are high chances to get > frustrated and burned out on the way afaics. Yeah, I understand that. No offense people, but after reading some of the recurring threads I was ready to go jump out of the nearest window. Given the previous threads I personally don't have much hope that repotags will be ever accepted by the Fedora community and regretfully I don't have any magical political solution to the problem - it does look to me that most of the objections are political in nature. -- Fernando From Axel.Thimm at ATrpms.net Fri May 18 18:02:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 May 2007 20:02:38 +0200 Subject: EPEL report 2007, week 19 In-Reply-To: <1179507009.10500.7.camel@cmn15.stanford.edu> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> Message-ID: <20070518180238.GB22950@neu.nirvana> On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > Yeah, I understand that. No offense people, but after reading some of > the recurring threads I was ready to go jump out of the nearest window. I hope that you live on the ground floor :) > Given the previous threads I personally don't have much hope that > repotags will be ever accepted by the Fedora community be careful: don't confuse the whole community with a couple of people sitting behind the steering wheel. fpc had signaled that they would pass any decision of epel to introduce repotags and fesco couldn't care less, they don't like the idea of repotags (especially from their non-rhel pov), but they wouldn't veto any such decision either. In fact I would argue that the Fedora and - what's more important in this context - the RHEL community were quite accustomed and happy with repotags. But repotags have a very week point: It takes one player to taint the system. > and regretfully I don't have any magical political solution to the > problem - it does look to me that most of the objections are > political in nature. Well, for what it's worth the repotag issue was never introduced in any non-political way. It is the way that repos used to visually mark their packages like marking cattles. They don't produce more or less milk either, but when a cattle breaks free and stampedes your meadow to dirt you know what farmer to blame. Same for packages. It was never a "technical" issue that Dag's repotag "dag" was higher than ATrpms' "at". Neither that "rf" was higher that "ccrma" and so on. These "technical" arguments are rather lame, and if the people having these arguments really belived in them, they would in fact want a repotag of "zzz_my_repo". There are no technical benefits or drawbacks with repotags. So it started by politics (a common request of many existing and to become software repos for RHEL) and ended with politics (epel effectively rejecting to play along). And even hiding behind being a homo faber, e.g. ignoring all but technical sides of any issue, is already a political statement. There is nothing wrong with politics per se, it would just had been nice if politics would had been layed out into nice inter-repo cooperation. Instead we now have the same political rift that Fedora itself had 3 years ago. Fedora's rifts are still not completely healed, let's see how long it will take until epel vs the rest of world rifts start to heal. It is just sad to see the exact same mistakes recurring again. And even sader it is to be in the middle of it again. Anyway, Nando, as much as I personally liked and promoted repotags, it's currently more promising to beat a dead horse than to get epel to consider repotags, after all epel already voted on this and nothing has changed since. So I wouldn't invest too much time into this, if I were you, because you will just burn out as the rest of us. I know I burnt out now for the umpteenth time. :/ -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nando at ccrma.Stanford.EDU Sat May 19 18:06:15 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sat, 19 May 2007 11:06:15 -0700 Subject: EPEL report 2007, week 19 In-Reply-To: <20070518180238.GB22950@neu.nirvana> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> Message-ID: <1179597975.12614.22.camel@cmn15.stanford.edu> On Fri, 2007-05-18 at 20:02 +0200, Axel Thimm wrote: > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > > Yeah, I understand that. No offense people, but after reading some of > > the recurring threads I was ready to go jump out of the nearest window. > > I hope that you live on the ground floor :) Don't worry, I can hopefully resist the rige :-) > > Given the previous threads I personally don't have much hope that > > repotags will be ever accepted by the Fedora community > > be careful: don't confuse the whole community with a couple of people > sitting behind the steering wheel. fpc had signaled that they would > pass any decision of epel to introduce repotags and fesco couldn't > care less, they don't like the idea of repotags (especially from their > non-rhel pov), but they wouldn't veto any such decision either. Sorry, I did not mean to do that, there have been voices of support, of course. But those opposed do speak for the community (whatever that is) and they have the wheel. > In fact I would argue that the Fedora and - what's more important in > this context - the RHEL community were quite accustomed and happy with > repotags. > > But repotags have a very week point: It takes one player to taint the > system. > > > and regretfully I don't have any magical political solution to the > > problem - it does look to me that most of the objections are > > political in nature. > > Well, for what it's worth the repotag issue was never introduced in any > non-political way. It is the way that repos used to visually mark > their packages like marking cattles. They don't produce more or less > milk either, but when a cattle breaks free and stampedes your meadow > to dirt you know what farmer to blame. > > Same for packages. It was never a "technical" issue that Dag's repotag > "dag" was higher than ATrpms' "at". Neither that "rf" was higher that > "ccrma" and so on. These "technical" arguments are rather lame, and if > the people having these arguments really belived in them, they would > in fact want a repotag of "zzz_my_repo". There are no technical > benefits or drawbacks with repotags. That particular one not even qualifies as an "argument" (IMHO), it can be disproved as a problem in a few lines - reductio ad absurdum - if the person at the other end is listening (and that's the problem). For the record, the only "technical issue" that I felt was technical in the list I wrote about was technical issues with respect to how to implement this in the build system. The rest are non-technical from my point of view (they are wishful thinking, or distractions from the issue at hand, just plain bad logic or criticism about the quality of the solution with no concrete plans for a better alternative - except for the suggestion of somehow using the pgp signatures for that purpose). [MUNCH] > Anyway, Nando, as much as I personally liked and promoted repotags, > it's currently more promising to beat a dead horse than to get epel to > consider repotags, after all epel already voted on this and nothing > has changed since. Yup, I know. Don't worry, I don't _have_ that much time to invest :-) When I see an email asking about this issue I'll try to answer (if there is anything to say and I have time to say it), if I see objections I'll do my best to answer them (I already did that a couple of times and there were no responses to my answers). That's it... -- Fernando From nando at ccrma.Stanford.EDU Sun May 20 00:58:41 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sat, 19 May 2007 17:58:41 -0700 Subject: EPEL report 2007, week 19 In-Reply-To: <1179597975.12614.22.camel@cmn15.stanford.edu> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> <1179597975.12614.22.camel@cmn15.stanford.edu> Message-ID: <1179622721.13224.2.camel@cmn15.stanford.edu> On Sat, 2007-05-19 at 11:06 -0700, Fernando Lopez-Lezcano wrote: > On Fri, 2007-05-18 at 20:02 +0200, Axel Thimm wrote: > > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > > > Yeah, I understand that. No offense people, but after reading some of > > > the recurring threads I was ready to go jump out of the nearest window. > > > > I hope that you live on the ground floor :) > > Don't worry, I can hopefully resist the rige :-) I have no clue what "rige" might be but I'll resist it anyway, I actually tried to type "urge" and that came out... -- Fernando From Axel.Thimm at ATrpms.net Sun May 20 01:05:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 20 May 2007 03:05:28 +0200 Subject: EPEL report 2007, week 19 In-Reply-To: <1179622721.13224.2.camel@cmn15.stanford.edu> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> <1179597975.12614.22.camel@cmn15.stanford.edu> <1179622721.13224.2.camel@cmn15.stanford.edu> Message-ID: <20070520010528.GA27737@neu.nirvana> On Sat, May 19, 2007 at 05:58:41PM -0700, Fernando Lopez-Lezcano wrote: > On Sat, 2007-05-19 at 11:06 -0700, Fernando Lopez-Lezcano wrote: > > On Fri, 2007-05-18 at 20:02 +0200, Axel Thimm wrote: > > > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > > > > Yeah, I understand that. No offense people, but after reading some of > > > > the recurring threads I was ready to go jump out of the nearest window. > > > > > > I hope that you live on the ground floor :) > > > > Don't worry, I can hopefully resist the rige :-) > > I have no clue what "rige" might be but I'll resist it anyway, I > actually tried to type "urge" and that came out... I was wondering about that - "rige" is the name of one of my cats. She never really tried to push people out of windows until now. :=) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun May 20 12:10:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 14:10:28 +0200 Subject: EPEL report week 20, 2007 Message-ID: <46503AB4.8020103@leemhuis.info> Hi all! Please find below this weeks EPEL report. It's also in the wiki at http://fedoraproject.org/wiki/EPEL/Reports/Week20 Cu thl ---- = Weekly EPEL Summary = Week 20/2007 == Most important happenings == * mether (RahulSundaram) did some proof reading and cleanups in various EPEL documents in the wiki; thx for your help mether! quaid (KarstenWade) is also working on cleaning up the wiki. * "start signal" for Fedora contributors was send; see https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00323.html ; EPEL got quite some new contributors and packages due to it * [https://www.redhat.com/archives/epel-devel-list/2007-May/msg00052.html some discussions] about the proper update strategy for packages == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) Stahnma (MichaelStahnke) just missed the meeting. Others that participated the meeting: Jeff_S, lmacken, smooge === Summary === * 00:02 -- repotags/interaction with 3rd party repos -- owner: all * we wait for more discussion on the list (in particular for Fernando Lopez-Lezcano before we decide how to move on) * knurd also want to discuss cooperation with CentOS/z00dax a bit, which might have impact to this, too * 00:04 -- vacant seat in the steering committee * knurd mailed those five people thimm proposed; four answered; they gave a "no" or a "only if you don't find somebody else" kind of answers; we wait another week and evaluate; maybe z00dax could join the Steering Committee (even without being a contributor for EPEL, as he can't sign the CLA) * 00:06 -- finish the wiki docs and remove the warnings * mether and quaid did some cleanups; quaid will do some more over the next few days; the plan is to remove the those "not official yet" warning by next weeks meeting, but the EPEL repo itself stays unannounced * some discussion about bodhi with lmacken under this topic; see full log for details * 00:14 -- Free discussion around EPEL * 00:15 nirik asked for comments regarding Xfce in EPEL, as Xfce will soon get into CentOS Extras, too; (see full log for details); knurd mentions that we should have it in EPEL, even if CentOS Extras has it, but we should try to find a way of cooperation so bugfixes find their way into CentOS Extras, EPEL and Fedora * 00:20 nirik> "oh, how about mock configs?" dgilmore will make sure they work * 00:25 smooge> "Will we be answering who the EPEL customers are thought to be to distinguish it from other customer bases?"; we continue on the list, but we maybe should write something up and put it in the wiki * 00:26 some discussions about RHEL subscriptions for testing; quiad "I haven't gotten too far with that ... still looking for the right person"; lots of people say that CentOS should be god enough for testing normally; but having some testboxes with RHEL around might be helpful === Full meeting log === See https://www.redhat.com/archives/epel-devel-list/2007-May/msg00088.html == Stats == === General === Number of EPEL Contributors 74 We welcome 13 new contributors: dcm_AT_acm.org, dev_AT_nigelj.com, eric.tanguy_AT_univ-nantes.fr, fedora_AT_theholbrooks.org, frank-buettner_AT_gmx.net, gajownik_AT_gmail.com, gilboad_AT_gmail.com, jeff.gilchrist_AT_gmail.com, jwb_AT_redhat.com, lxtnow_AT_gmail.com, mfleming+rpm_AT_enlartenment.com, ruben_AT_rubenkerkhof.com, trond.danielsen_AT_gmail.com === EPEL 5 === Number of source packages: 274 Number of binary packages: 437 There are 49 new Packages: * autodir | Creates user directories on demand * cgdb | CGDB is a curses-based interface to the GNU Debugger (GDB) * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * drgeo | Interactive educational geometry software * freehdl | GPLed free VHDL * gperiodic | Program for browsing the periodic table * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * incron | Inotify cron system * ircd-hybrid | Internet Relay Chat Server * libiptcdata | IPTC tag library * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * nrpe | Host/service/network monitoring agent for Nagios * ocaml | Objective Caml compiler and programming environment * pdns | A modern, advanced and high performance authoritative-only nameserver * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-DBD-SQLite | Self Contained RDBMS in a DBI Driver * perl-HTML-Table | Create HTML tables using simple interface * perl-IO-Multiplex | IO-Multiplex module for perl * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * php-channel-phpunit | Adds phpunit channel to PEAR * php-pear-DB | PEAR: Database Abstraction Layer * php-pear-Log | Abstracted logging facility for PHP * php-pecl-radius | Radius client library * php-pecl-xdebug | PECL package for debugging PHP scripts * Pound | Reverse proxy and load balancer * python-cheetah | Template engine and code-generator * python-docutils | A system for processing plaintext documentation * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * python-protocols | Open Protocols and Component Adaptation for Python * python-sqlite2 | DB-API 2.0 interface for SQLite 3.x * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * ushare | UPnP (TM) A/V Media Server * windowlab | Small and Simple Amiga-like Window Manager * yum-arch | Extract headers from rpm in a old yum repository === EPEL 4 === Number of source packages: 186 Number of binary packages: 348 There are 28 new Packages: * bugzilla | Bug tracking system * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * freehdl | GPLed free VHDL * gperiodic | Program for browsing the periodic table * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * ircd-hybrid | Internet Relay Chat Server * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * ocaml | Objective Caml compiler and programming environment * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-HTML-Table | Create HTML tables using simple interface * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * Pound | Reverse proxy and load balancer * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * windowlab | Small and Simple Amiga-like Window Manager From fedora at leemhuis.info Sun May 20 13:19:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 15:19:50 +0200 Subject: repotags (was Re: EPEL report 2007, week 19) In-Reply-To: <20070518180238.GB22950@neu.nirvana> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> Message-ID: <46504AF6.6040302@leemhuis.info> On 18.05.2007 20:02, Axel Thimm wrote: > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > [...] > fpc had signaled that they would > pass any decision of epel to introduce repotags Hmm, I got different signals from Spot, which leads the Fedora Packaging Committee. See: https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01393.html Quoting ---- But I'd like to point out that I'm still fundamentally opposed to the repotag, as I've yet to hear what problem it solves, aside from the "other repos want it" problem. ~spot -- And below is something from #fedora-devel from some weeks ago after I send https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html ---- 14:59 < knurd> | rdieter, spot, @FPC -- will you talk about the repotag issue in todays meeting? 14:59 < spot> | knurd: if someone submits a draft. 15:00 < knurd> | spot, well, you seem to be still opposed to the idea 15:00 < spot> | http://fedoraproject.org/wiki/Packaging/Committee 15:01 < spot> | not to be rude, but, you proposed "lets do repotags!" 15:01 < spot> | i'm far far more interested in "what problem are we trying to solve?" 15:02 < spot> | daniel_hozac: no, that's the disttag 15:02 < rdieter> | spot: the problem is clear (hopefully not debatable): same pkg in multiple repos. 15:02 < knurd> | spot, I only try to solve the problem "outside people yell at EPEL and are makeing it look bad because it doesn't use repotags" 15:02 < spot> | rdieter: so, repotag doesn't really solve that problem. 15:02 < daniel_hoza> | spot: but it's also the repotag for all Fedora packages? 15:02 < knurd> | spot, one of them is in FPC 15:02 < knurd> | spot, so all I want is politics 15:03 < rdieter> | spot: agreed, but it helps. it's not 100% a technical issue either (far from it). sigh. 15:04 < spot> | rdieter: i'm not sure that it helps. if foo-1.0.0-1.epel trumps foo-1.0.0-1.rf ... won't rf get mad? 15:05 < knurd> | spot, .rf is higher then .epel 15:05 < rdieter> | spot: repotag trumping is better than identical EVR's. 15:05 < spot> | rdieter: i suppose that depends on which repo you wanted that package to come from 15:07 < spot> | i'm not sure if adding them is harmless 15:07 < spot> | it complicates release ordering 15:08 < spot> | and n-v-r comparison 15:08 < spot> | and adds hacks to the buildsystem 15:08 < knurd> | spot, or spec files 15:08 < rdieter> | spot: if adding repotag to the end of Release causes problems, it is only exposing problems that already existed. 15:08 < spot> | rdieter: no, its exposing problems i intentionally avoided when i wrote the first naming drafts 15:09 < spot> | i didn't want any unnecessary non-numeric characters in the n-v-r 15:09 < spot> | the repotag is "unnecessary non-numeric characters" 15:09 < knurd> | spot, +1 15:10 < spot> | so far, the only technical reason I've heard is that it helps us mix repos, which we're not trying to do anyways, because our tools don't help us mix these repos with or without repotags 15:10 < spot> | which leaves us with political reasons, in that the other 3rd party RHEL repos want us to do it. 15:11 < spot> | the only way I can see supporting repotags in the FPC is part of a much broader agreement between EPEL and the other repos 15:12 < spot> | to collaborate and focus on supporting mixing the repos. 15:12 < knurd> | spot, that would mean Fedora probably as well 15:12 < knurd> | spot, why only EPEL then 15:12 < spot> | if all the repos say "mixing is our goal. we will do X and Y and Z to make sure that users don't have pain." 15:12 < spot> | knurd: because as Dag and Karambir told me, they don't care about Fedora. 15:13 < spot> | they don't do new packages for Fedora anymore 15:13 < knurd> | spot, but others do 15:13 < spot> | knurd: afaik, atrpms is the only one of significant size 15:13 < spot> | other than dribble/livna, which already have mixing as a marked goal 15:14 < knurd> | spot, and dries, which is part of rpmforge: http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/fc6/i386/RPMS.dries/ 15:30 < spot> | rdieter: ok, thanks. ---- Spot's signals are the reasons why I don't want to invest more of *my* time to get repotags for EPEL. > and fesco couldn't > care less, they don't like the idea of repotags (especially from their > non-rhel pov), but they wouldn't veto any such decision either. Likely. But just FYI: FESCo itself decided against repotags in the past for EPEL (in the early EPEL days), too. CU thl From fedora at leemhuis.info Sun May 20 13:49:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 15:49:47 +0200 Subject: repotags proposal Message-ID: <465051FB.3030604@leemhuis.info> I wrote a quick proposal for repotags in EPEL. If people really want repotags in EPEL please speak up in this thread -- I'd really like to see that contributors really want repotags before I propose this proposal for voting in a SIG meeting. == Proposal for the use of repotags for EPEL == The EPEL Steering Committee hereby gives a agreement to use a ".epel" repotag for all newly build packages in the EPEL repositories for EL4 and EL5. It's just an agreement to start using repotags after people that are interested in repotags worked out a technical solution. Before that solution is getting realized in EPEL it has o be proposed to and accepted by the Fedora Packaging Committee, which is responsible for the rules around writing spec files for EPEL (and Fedora) and thus has a word to say in this discussion, too. The EPEL Steering Committee gives this agreement only as long as following points are meet by the technical solution: * it must remain possible to simply copy spec files between Fedora and EPEL branches without modifications * no hacks to the buildsys or modifications to the rpms after their initial creation * the repotag must be used my all packages * no abuse of the disttag That agreement if given for EL4 and EL5 only -- the EPEL Steering Committee would like to see a technical solution that properly solves the problem repotags are trying to solve currently. == EOF == CU thl From dag at wieers.com Sun May 20 14:00:19 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 20 May 2007 16:00:19 +0200 (CEST) Subject: repotags (was Re: EPEL report 2007, week 19) In-Reply-To: <46504AF6.6040302@leemhuis.info> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> <46504AF6.6040302@leemhuis.info> Message-ID: On Sun, 20 May 2007, Thorsten Leemhuis wrote: > On 18.05.2007 20:02, Axel Thimm wrote: > > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > > [...] > > fpc had signaled that they would > > pass any decision of epel to introduce repotags > > Hmm, I got different signals from Spot, which leads the Fedora Packaging > Committee. > > See: > > https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01393.html > > Quoting > ---- > But I'd like to point out that I'm still fundamentally opposed to the > repotag, as I've yet to hear what problem it solves, aside from the > "other repos want it" problem. Ok, this is silly. spot should have joined the discussion instead of iterating over the same arguments brought up on this list. 1. repotags makes packages unique (cross-repositories) (yes, this means you have to believe in a world where there is more than just EPEL, stop reading here if you don't believe in that) 2. repotags do not affect the version comparison in a useful way (since there is no point in comparing release tags between repositories anyway, there is no relation) 3. repotags help identify packages in every output (you can talk about extra headers and changing RPM, we don't have that today and unless Red Hat commits to backporting RPM support for repotags we won't have that tomorrow either) With a Fedora hat, I can understand that people think 'who cares, we never needed it in Fedora, so why do we need it in EPEL' ? But that is shortsighted. Asking to do rpm -qpi or anything else just worsten the experience for users and is a waste of time for anyone trying to help out. Sure, RPM could be changed to support it outside of the release-tag. Sure, Yum is not the best tool to support mixing repositories because it does not allow easily to select specific packages from specific repos. All that can be improved, but without the mindset that there is more than one repository, all these changes will never happen. And I personally blame Fedora's single repo mindset as the main reason why the current situation is bad. Before Yum existed (apt) and with Smart these issues did/do not exist especially because they were designed to select 'other' versions of a package. The big problem with EPEL is that people that use Fedora mainly are in charge of making the rules, and spot's expression is right on that spot. (Did spot ever use RPMforge or ATrpms on RHEL/CentOS from within Yum, Apt or Smart ?) Since it is pretty clear that CentOS Extras and EPEL will be seperate projects packaging the same RPMs, I hope some people wake up and realise that the Fedora mindset does not belong in EPEL. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Sun May 20 14:02:12 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 20 May 2007 16:02:12 +0200 (CEST) Subject: repotags proposal In-Reply-To: <465051FB.3030604@leemhuis.info> References: <465051FB.3030604@leemhuis.info> Message-ID: On Sun, 20 May 2007, Thorsten Leemhuis wrote: > I wrote a quick proposal for repotags in EPEL. If people really want > repotags in EPEL please speak up in this thread -- I'd really like to > see that contributors really want repotags before I propose this > proposal for voting in a SIG meeting. > > == Proposal for the use of repotags for EPEL == > > The EPEL Steering Committee hereby gives a agreement to use a ".epel" > repotag for all newly build packages in the EPEL repositories for EL4 > and EL5. It's just an agreement to start using repotags after people > that are interested in repotags worked out a technical solution. Before > that solution is getting realized in EPEL it has o be proposed to and > accepted by the Fedora Packaging Committee, which is responsible for the > rules around writing spec files for EPEL (and Fedora) and thus has a > word to say in this discussion, too. > > The EPEL Steering Committee gives this agreement only as long as > following points are meet by the technical solution: > > * it must remain possible to simply copy spec files between Fedora and > EPEL branches without modifications > > * no hacks to the buildsys or modifications to the rpms after their > initial creation > > * the repotag must be used my all packages > > * no abuse of the disttag > > That agreement if given for EL4 and EL5 only -- the EPEL Steering > Committee would like to see a technical solution that properly solves > the problem repotags are trying to solve currently. > > == EOF == That's like saying: we do want to look at it objectively, but here are some requirements that make it impossible to implement. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From fedora at leemhuis.info Sun May 20 15:16:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 17:16:38 +0200 Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> Message-ID: <46506656.8060904@leemhuis.info> On 20.05.2007 16:02, Dag Wieers wrote: > On Sun, 20 May 2007, Thorsten Leemhuis wrote: > >> I wrote a quick proposal for repotags in EPEL. If people really want >> repotags in EPEL please speak up in this thread -- I'd really like to >> see that contributors really want repotags before I propose this >> proposal for voting in a SIG meeting. >> >> == Proposal for the use of repotags for EPEL == >> [...] >> == EOF == > > That's like saying: we do want to look at it objectively, but here are > some requirements that make it impossible to implement. Thanks for your detailed and helpful feedback. I propose this here for discussion. So if you have a technical solution that could work, but does not confirm to the points of the proposal? Then please show or explain it, that we can consider adjusting the proposal before it's being voted upon. That why I posted it for discussion. Ohh, sorry, I nearly forgot: there is a technical solution that could work. I outlined it in https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html In short: add a %{?repotag} to the end of release in all EPEL spec files, set that in the EPEL builders (not in the Fedora ones) to ".epel" and the solution is there. We could start with it tomorrow -- but we need the Fedora Packaging Committee to agree first, as that's responsible for stuff like this in Fedora. Cu thl From dag at wieers.com Sun May 20 15:36:36 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 20 May 2007 17:36:36 +0200 (CEST) Subject: repotags proposal In-Reply-To: <46506656.8060904@leemhuis.info> References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> Message-ID: On Sun, 20 May 2007, Thorsten Leemhuis wrote: > On 20.05.2007 16:02, Dag Wieers wrote: > > On Sun, 20 May 2007, Thorsten Leemhuis wrote: > > > >> I wrote a quick proposal for repotags in EPEL. If people really want > >> repotags in EPEL please speak up in this thread -- I'd really like to > >> see that contributors really want repotags before I propose this > >> proposal for voting in a SIG meeting. > >> > >> == Proposal for the use of repotags for EPEL == > >> [...] > >> == EOF == > > > > That's like saying: we do want to look at it objectively, but here are > > some requirements that make it impossible to implement. > > Thanks for your detailed and helpful feedback. I propose this here for > discussion. So if you have a technical solution that could work, but > does not confirm to the points of the proposal? Then please show or > explain it, that we can consider adjusting the proposal before it's > being voted upon. That why I posted it for discussion. Well, in our case the buildsystem takes care of adding the repotag. Since it needs to come at the very last there's no problem doing that. And it does not affect anyone maintaining the SPEC files. What's more you can leave it out for the Fedora builds, and add it for the EPEL builds. > Ohh, sorry, I nearly forgot: there is a technical solution that could > work. I outlined it in > https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html > > In short: add a %{?repotag} to the end of release in all EPEL spec > files, set that in the EPEL builders (not in the Fedora ones) to ".epel" > and the solution is there. We could start with it tomorrow -- but we > need the Fedora Packaging Committee to agree first, as that's > responsible for stuff like this in Fedora. This solution will never be accepted by Fedora because of practical problems: * it must remain possible to simply copy spec files between Fedora and EPEL branches without modifications * the repotag must be used my all packages Since it affects all Fedora packagers you will get objections from most maintainers, especially because it will not be used for Fedora. The obvious question will be: 'why introduce it in all SPEC files if we don't use it for Fedora ?'. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From fedora at leemhuis.info Sun May 20 16:07:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 18:07:12 +0200 Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> Message-ID: <46507230.1080509@leemhuis.info> On 20.05.2007 17:36, Dag Wieers wrote: > On Sun, 20 May 2007, Thorsten Leemhuis wrote: >> On 20.05.2007 16:02, Dag Wieers wrote: >>> On Sun, 20 May 2007, Thorsten Leemhuis wrote: >>>> I wrote a quick proposal for repotags in EPEL. If people really want >>>> repotags in EPEL please speak up in this thread -- I'd really like to >>>> see that contributors really want repotags before I propose this >>>> proposal for voting in a SIG meeting. >>>> == Proposal for the use of repotags for EPEL == >>>> [...] >>>> == EOF == >>> That's like saying: we do want to look at it objectively, but here are >>> some requirements that make it impossible to implement. >> Thanks for your detailed and helpful feedback. I propose this here for >> discussion. So if you have a technical solution that could work, but >> does not confirm to the points of the proposal? Then please show or >> explain it, that we can consider adjusting the proposal before it's >> being voted upon. That why I posted it for discussion. > Well, in our case the buildsystem takes care of adding the repotag. Just out of interest: how? > Since > it needs to come at the very last there's no problem doing that. And it > does not affect anyone maintaining the SPEC files. What's more you can > leave it out for the Fedora builds, and add it for the EPEL builds. Well, I could live with the buildsys adding it. But I'd prefer not to go with special patches, thus I'd would be best if patches that make this work get integrated directly into mock. But: >> Ohh, sorry, I nearly forgot: there is a technical solution that could >> work. I outlined it in >> https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html >> >> In short: add a %{?repotag} to the end of release in all EPEL spec >> files, set that in the EPEL builders (not in the Fedora ones) to ".epel" >> and the solution is there. We could start with it tomorrow -- but we >> need the Fedora Packaging Committee to agree first, as that's >> responsible for stuff like this in Fedora. > This solution will never be accepted by Fedora because of practical > problems: > * it must remain possible to simply copy spec files between Fedora and > EPEL branches without modifications > * the repotag must be used my all packages > Since it affects all Fedora packagers you will get objections from most > maintainers, especially because it will not be used for Fedora. The > obvious question will be: 'why introduce it in all SPEC files if we don't > use it for Fedora ?'. Nobody said that we need to use it everywhere in Fedora-only packages. But it should be allowed there. That afaics should be acceptable A special repotag macro has one benefit (and that's why I currently think it's the best solution): the spec file could be exchanged easily with other repos. Just define the individual repotag and rebuild one spec file in different repos (dag, CentOS Extras, EPEL, , ...). Cu thl Cu thl From dag at wieers.com Sun May 20 16:21:18 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 20 May 2007 18:21:18 +0200 (CEST) Subject: repotags proposal In-Reply-To: <46507230.1080509@leemhuis.info> References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> Message-ID: On Sun, 20 May 2007, Thorsten Leemhuis wrote: > On 20.05.2007 17:36, Dag Wieers wrote: > > On Sun, 20 May 2007, Thorsten Leemhuis wrote: > >> On 20.05.2007 16:02, Dag Wieers wrote: > >>> On Sun, 20 May 2007, Thorsten Leemhuis wrote: > >>>> I wrote a quick proposal for repotags in EPEL. If people really want > >>>> repotags in EPEL please speak up in this thread -- I'd really like to > >>>> see that contributors really want repotags before I propose this > >>>> proposal for voting in a SIG meeting. > >>>> == Proposal for the use of repotags for EPEL == > >>>> [...] > >>>> == EOF == > >>> That's like saying: we do want to look at it objectively, but here are > >>> some requirements that make it impossible to implement. > >> Thanks for your detailed and helpful feedback. I propose this here for > >> discussion. So if you have a technical solution that could work, but > >> does not confirm to the points of the proposal? Then please show or > >> explain it, that we can consider adjusting the proposal before it's > >> being voted upon. That why I posted it for discussion. > > Well, in our case the buildsystem takes care of adding the repotag. > > Just out of interest: how? Rewriting the SPEC file before using. The buildsystem does other stuff as well, like trimming the changelog and hardcoding Packager and Vendor information. (Yes, I like to have that in the SPEC file explicitely) In fact, I have a set of scripts in a plugin directory that are being called at different stages. These are being called on the SPEC file content. > > Since > > it needs to come at the very last there's no problem doing that. And it > > does not affect anyone maintaining the SPEC files. What's more you can > > leave it out for the Fedora builds, and add it for the EPEL builds. > > Well, I could live with the buildsys adding it. But I'd prefer not to go > with special patches, thus I'd would be best if patches that make this > work get integrated directly into mock. > > But: > > >> Ohh, sorry, I nearly forgot: there is a technical solution that could > >> work. I outlined it in > >> https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html > >> > >> In short: add a %{?repotag} to the end of release in all EPEL spec > >> files, set that in the EPEL builders (not in the Fedora ones) to ".epel" > >> and the solution is there. We could start with it tomorrow -- but we > >> need the Fedora Packaging Committee to agree first, as that's > >> responsible for stuff like this in Fedora. > > This solution will never be accepted by Fedora because of practical > > problems: > > * it must remain possible to simply copy spec files between Fedora and > > EPEL branches without modifications > > * the repotag must be used my all packages > > Since it affects all Fedora packagers you will get objections from most > > maintainers, especially because it will not be used for Fedora. The > > obvious question will be: 'why introduce it in all SPEC files if we don't > > use it for Fedora ?'. > > Nobody said that we need to use it everywhere in Fedora-only packages. > But it should be allowed there. That afaics should be acceptable > > A special repotag macro has one benefit (and that's why I currently > think it's the best solution): the spec file could be exchanged easily > with other repos. Just define the individual repotag and rebuild one > spec file in different repos (dag, CentOS Extras, EPEL, , > ...). Well, remember the disttag ? RPMforge was using that and Fedora took the idea and added a dot in the macro that made it impossible to use it the way we did. Broke our implementation and made things incompatible :) If mock can add the disttag, I don't see a need to have it as a macro. It is not something you use for anything else. (Unlike our use of the disttag) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From eric.tanguy at univ-nantes.fr Sun May 20 18:04:58 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 20 May 2007 20:04:58 +0200 Subject: Mock for EPEL In-Reply-To: <1179473506.11111.34.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <1179473506.11111.34.camel@bureau.maison> Message-ID: <1179684299.8858.0.camel@bureau.maison> Le vendredi 18 mai 2007 ? 09:31 +0200, Tanguy Eric a ?crit : > Le jeudi 17 mai 2007 ? 12:24 +0200, Thorsten Leemhuis a ?crit : > > > > On 17.05.2007 11:51, Tanguy Eric wrote: > > > Le jeudi 17 mai 2007 ? 11:38 +0200, Thorsten Leemhuis a ?crit : > > >> On 17.05.2007 11:30, Tanguy Eric wrote: > > >>> Le jeudi 17 mai 2007 ? 11:16 +0200, Thorsten Leemhuis a ?crit : > > >>>> On 17.05.2007 11:00, Remi Collet wrote: > > >>>>> Tanguy Eric a ?crit : > > > Thanks it seems better now but i still have a problem : > > > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > > > init > > > clean > > > prep > > > This may take a while > > > Error: Cannot find a valid baseurl for repo: extras > > > > > > Error performing yum command: /usr/sbin/mock-helper yum > > > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > > > ending > > > done > > > > Seem there is some problem with the mirrorlist creation on the Fedora > > servers -- > > http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 > > returns an empty list. > > > > Hardcode the repo from http://download.fedora.redhat.com/pub/epel/ > > directly for now -- for example use > > > > [extras] > > name=epel > > #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 > > baseurl=http://download.fedora.redhat.com/pub/epel/4/i386/ > > > > for EPEL4-i386 > > > One more problem this morning : > $ mock -r fedora-4-i386-epel drgeo-1.1.0-5.el4.src.rpm > init > clean > prep > This may take a while > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Fri, 18 May 2007 07:30:34 GMT > Server: Apache/2.0.52 > Content-Length: 342 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > Trying other mirror. > Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] > No more mirrors to try. > > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > ending > done > No one can help me to undrestand why there is this problem ? Thanks Eric From Axel.Thimm at ATrpms.net Sun May 20 14:01:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 20 May 2007 16:01:28 +0200 Subject: repotags (was Re: EPEL report 2007, week 19) In-Reply-To: <46504AF6.6040302@leemhuis.info> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> <46504AF6.6040302@leemhuis.info> Message-ID: <20070520140128.GA16848@neu.nirvana> On Sun, May 20, 2007 at 03:19:50PM +0200, Thorsten Leemhuis wrote: > On 18.05.2007 20:02, Axel Thimm wrote: > > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: > > [...] > > fpc had signaled that they would > > pass any decision of epel to introduce repotags > > Hmm, I got different signals from Spot, which leads the Fedora Packaging > Committee. > > See: > > https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01393.html > > Quoting > ---- > But I'd like to point out that I'm still fundamentally opposed to the > repotag, as I've yet to hear what problem it solves, aside from the > "other repos want it" problem. > > ~spot a) spot is not an inanimate object b) quoting only half the quotes always biases towards your view, of course. There is also: "Indeed. I'm not necessarily opposed to the repotag being part of %{dist} for EPEL, but I am opposed to making %{dist} mandatory. [...] ~spot" (and you were part of that thread) c) contrary to epel's leadership structure fpc works democratic w/o an overpowered chairman, so even if spot would vote against it, there are still N-1 other voters And BTW I'm in no mood to start picking up infinite threads with you again. Really. You want to present as if all the world, but you blocked repotags, that's fine. In reality it was really you as a major opponent to repotags that brought us here. Do I sound like I'm pissed off? Maybe I do, and maybe I am. I just don't like playing hide and seek or "pass the old maid". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun May 20 18:17:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 20:17:09 +0200 Subject: Mock for EPEL In-Reply-To: <1179684299.8858.0.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <1179473506.11111.34.camel@bureau.maison> <1179684299.8858.0.camel@bureau.maison> Message-ID: <465090A5.9040305@leemhuis.info> On 20.05.2007 20:04, Tanguy Eric wrote: > No one can help me to undrestand why there is this problem ? Try again, I confident the problem will be gone. It was likely bad timing -- maybe you downloaded the metadata from the needsign repo before/during a push and the package for deleted when yum tried to download it. Well, something like that probably. CU thl From eric.tanguy at univ-nantes.fr Sun May 20 18:19:56 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 20 May 2007 20:19:56 +0200 Subject: Mock for EPEL In-Reply-To: <465090A5.9040305@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <1179473506.11111.34.camel@bureau.maison> <1179684299.8858.0.camel@bureau.maison> <465090A5.9040305@leemhuis.info> Message-ID: <1179685196.8858.2.camel@bureau.maison> Le dimanche 20 mai 2007 ? 20:17 +0200, Thorsten Leemhuis a ?crit : > On 20.05.2007 20:04, Tanguy Eric wrote: > > No one can help me to undrestand why there is this problem ? > > Try again, I confident the problem will be gone. It was likely bad > timing -- maybe you downloaded the metadata from the needsign repo > before/during a push and the package for deleted when yum tried to > download it. Well, something like that probably. > I just retry and still have this problem : $ mock -r fedora-4-i386-epel drgeo-1.1.0-6.el4.src.rpm init clean prep This may take a while http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Sun, 20 May 2007 18:19:13 GMT Server: Apache/2.0.52 Content-Length: 342 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] No more mirrors to try. Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build ending done Eric From fedora at leemhuis.info Sun May 20 18:20:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 20:20:36 +0200 Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> Message-ID: <46509174.4090109@leemhuis.info> On 20.05.2007 18:21, Dag Wieers wrote: > On Sun, 20 May 2007, Thorsten Leemhuis wrote: >> On 20.05.2007 17:36, Dag Wieers wrote: >>> On Sun, 20 May 2007, Thorsten Leemhuis wrote: >>>> On 20.05.2007 16:02, Dag Wieers wrote: >>>>> On Sun, 20 May 2007, Thorsten Leemhuis wrote: >>>>>> I wrote a quick proposal for repotags in EPEL. If people really want >>>>>> repotags in EPEL please speak up in this thread -- I'd really like to >>>>>> see that contributors really want repotags before I propose this >>>>>> proposal for voting in a SIG meeting. >>>>>> == Proposal for the use of repotags for EPEL == >>>>>> [...] >>>>>> == EOF == >>>>> That's like saying: we do want to look at it objectively, but here are >>>>> some requirements that make it impossible to implement. >>>> Thanks for your detailed and helpful feedback. I propose this here for >>>> discussion. So if you have a technical solution that could work, but >>>> does not confirm to the points of the proposal? Then please show or >>>> explain it, that we can consider adjusting the proposal before it's >>>> being voted upon. That why I posted it for discussion. >>> Well, in our case the buildsystem takes care of adding the repotag. >> Just out of interest: how? > Rewriting the SPEC file before using. [...] Well, that or something similar could be done in the scripts that create the srpm. That would be acceptable (and, btw, not directly "buildsystem" in Fedora-land). >>> Since >>> it needs to come at the very last there's no problem doing that. And it >>> does not affect anyone maintaining the SPEC files. What's more you can >>> leave it out for the Fedora builds, and add it for the EPEL builds. >> Well, I could live with the buildsys adding it. But I'd prefer not to go >> with special patches, thus I'd would be best if patches that make this >> work get integrated directly into mock. >> But: >>>> Ohh, sorry, I nearly forgot: there is a technical solution that could >>>> work. I outlined it in >>>> https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html >>>> >>>> In short: add a %{?repotag} to the end of release in all EPEL spec >>>> files, set that in the EPEL builders (not in the Fedora ones) to ".epel" >>>> and the solution is there. We could start with it tomorrow -- but we >>>> need the Fedora Packaging Committee to agree first, as that's >>>> responsible for stuff like this in Fedora. >>> This solution will never be accepted by Fedora because of practical >>> problems: >>> * it must remain possible to simply copy spec files between Fedora and >>> EPEL branches without modifications >>> * the repotag must be used my all packages >>> Since it affects all Fedora packagers you will get objections from most >>> maintainers, especially because it will not be used for Fedora. The >>> obvious question will be: 'why introduce it in all SPEC files if we don't >>> use it for Fedora ?'. >> Nobody said that we need to use it everywhere in Fedora-only packages. >> But it should be allowed there. That afaics should be acceptable >> >> A special repotag macro has one benefit (and that's why I currently >> think it's the best solution): the spec file could be exchanged easily >> with other repos. Just define the individual repotag and rebuild one >> spec file in different repos (dag, CentOS Extras, EPEL, , >> ...). > Well, remember the disttag ? RPMforge was using that and Fedora took the > idea and added a dot in the macro that made it impossible to use it the > way we did. Broke our implementation and made things incompatible :) No sorry, didn't know that. That was not nice -- we at Fedora could have simply used a different name for the macro. > If mock can add the disttag, I don't see a need to have it as a macro. > [...] disttag is optional in Fedora-land and some people (including me) want it to stay optional. Cu thl From smooge at gmail.com Sun May 20 18:23:31 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 20 May 2007 12:23:31 -0600 Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> Message-ID: <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> Could we please cut the animosity here. If people have nothing nice to say to each other, its time for everyone to sit in their corners for a while (and yes I have been spending the last week dealing with 5 year olds). At this point, the conversations between the various distro people has reached about the same level. If one side were to point out that the sky was blue, the others will point out that they saw it that way first. And if others points out that water is wet, the other side will point out that this is a corner case since steam and ice are not technically wet. We are becoming the poster children for Microsoft's next ad campaign: 'What Open Source Community Really Is'... -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From fedora at leemhuis.info Sun May 20 18:36:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 20:36:27 +0200 Subject: repotags (was Re: EPEL report 2007, week 19) In-Reply-To: <20070520140128.GA16848@neu.nirvana> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> <4645BCDE.2070203@leemhuis.info> <1178996675.12610.14.camel@cmn3.stanford.edu> <4646C6F7.4020607@leemhuis.info> <1179507009.10500.7.camel@cmn15.stanford.edu> <20070518180238.GB22950@neu.nirvana> <46504AF6.6040302@leemhuis.info> <20070520140128.GA16848@neu.nirvana> Message-ID: <4650952B.5050205@leemhuis.info> On 20.05.2007 16:01, Axel Thimm wrote: > On Sun, May 20, 2007 at 03:19:50PM +0200, Thorsten Leemhuis wrote: >> On 18.05.2007 20:02, Axel Thimm wrote: >>> On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote: >>> [...] >>> fpc had signaled that they would >>> pass any decision of epel to introduce repotags >> Hmm, I got different signals from Spot, which leads the Fedora Packaging >> Committee. >> See: >> https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01393.html >> Quoting >> ---- >> But I'd like to point out that I'm still fundamentally opposed to the >> repotag, as I've yet to hear what problem it solves, aside from the >> "other repos want it" problem. >> ~spot > a) spot is not an inanimate object Sorry, my english skills fail to parse that. What do did you mean? http://www.thefreedictionary.com/inanimate Did you mean something like "Spot can change his opinion"? > b) quoting only half the quotes always biases towards your view, of > course. There is also: > "Indeed. I'm not necessarily opposed to the repotag being part of > %{dist} for EPEL, but I am opposed to making %{dist} > mandatory. [...] ~spot" (and you were part of that thread) Sorry, the thread is some weeks old I don't remember each every detail. And I at least give pointers to the mails where somebody wrote something when I quote him. Further: I for one think a repotags only makes sense if it's used everywhere. Dist isn't used everywhere and not mandatory, thus I'd prefer not to abuse it. > c) contrary to epel's leadership structure fpc works democratic w/o an > overpowered chairman, The EPEL chairmen has no special powers. He just organizes and coordinates -- that includes voting and is part of being a chairmen job in my understanding (and done like that in FESCo, too). > so even if spot would vote against it, there > are still N-1 other voters I just mentioned what impression I got from talking to the FPC chairmen. Not more. Not less. Further: I know from Jesse's statement from a recent FESCo meeting that he is also against repotags. But yes, I don't know the other peoples opinion. Do you? I actually wanted to know what FPC thinks about the repotags (see the #fedora-devel quote in this thread) but didn't get one until today. > And BTW I'm in no mood to start picking up infinite threads with you > again. Really. You want to present as if all the world, but you > blocked repotags, that's fine. We did not understood us there. I back then was against a blind vote "EPEL uses repotags" without knowing the consequences for out packagers (e.g. the technical implementation details). So I voted for "no", even if I was not opposed heavily to repotags in general. > In reality it was really you as a major > opponent to repotags that brought us here. If someone that wanted repotags did now what I try to do now (e.g. get some row technical details in place before a voting) or worked out a solution with the Fedora Packaging Committee before doing the EPEL vote I might would have abstained a vote or might even have given a "+1" if the solution was sane. > Do I sound like I'm pissed off? Maybe I do, and maybe I am. I just > don't like playing hide and seek or "pass the old maid". Axel, I really wanted and want to have you participating in EPEL. I even wanted you in the Steering Committee -- that why I proposed you for it when I presented the proposal for a Steering Committee to FESCo. I still hope you can reconsider your leave and join us again. Cu thl From fedora at leemhuis.info Sun May 20 18:37:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 20:37:47 +0200 Subject: Mock for EPEL In-Reply-To: <1179685196.8858.2.camel@bureau.maison> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <1179473506.11111.34.camel@bureau.maison> <1179684299.8858.0.camel@bureau.maison> <465090A5.9040305@leemhuis.info> <1179685196.8858.2.camel@bureau.maison> Message-ID: <4650957B.5010705@leemhuis.info> On 20.05.2007 20:19, Tanguy Eric wrote: > Le dimanche 20 mai 2007 ? 20:17 +0200, Thorsten Leemhuis a ?crit : >> On 20.05.2007 20:04, Tanguy Eric wrote: >>> No one can help me to undrestand why there is this problem ? >> Try again, I confident the problem will be gone. It was likely bad >> timing -- maybe you downloaded the metadata from the needsign repo >> before/during a push and the package for deleted when yum tried to >> download it. Well, something like that probably. >> > I just retry and still have this problem : > $ mock -r fedora-4-i386-epel drgeo-1.1.0-6.el4.src.rpm > init > clean > prep > This may take a while > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Sun, 20 May 2007 18:19:13 GMT > Server: Apache/2.0.52 > Content-Length: 342 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > Trying other mirror. > Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] > No more mirrors to try. > > Error performing yum command: /usr/sbin/mock-helper yum > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > ending > done Is there a proxy between you and the internet? It might fool you. Whatever: this is definitely no problem in the EPEL mock configs. You can temporary work around it by disabling the needsign repo. CU thl From fedora at leemhuis.info Sun May 20 18:41:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 20:41:37 +0200 Subject: repotags proposal In-Reply-To: <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> Message-ID: <46509661.5070305@leemhuis.info> On 20.05.2007 20:23, Stephen John Smoogen wrote: > Could we please cut the animosity here. [...] Sorry, apart from maybe one mail in this sub-thread I found this discussion fruitful to understand each others points. CU thl From eric.tanguy at univ-nantes.fr Sun May 20 18:47:11 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 20 May 2007 20:47:11 +0200 Subject: Mock for EPEL In-Reply-To: <4650957B.5010705@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <1179473506.11111.34.camel@bureau.maison> <1179684299.8858.0.camel@bureau.maison> <465090A5.9040305@leemhuis.info> <1179685196.8858.2.camel@bureau.maison> <4650957B.5010705@leemhuis.info> Message-ID: <1179686831.8858.6.camel@bureau.maison> Le dimanche 20 mai 2007 ? 20:37 +0200, Thorsten Leemhuis a ?crit : > On 20.05.2007 20:19, Tanguy Eric wrote: > > Le dimanche 20 mai 2007 ? 20:17 +0200, Thorsten Leemhuis a ?crit : > >> On 20.05.2007 20:04, Tanguy Eric wrote: > >>> No one can help me to undrestand why there is this problem ? > >> Try again, I confident the problem will be gone. It was likely bad > >> timing -- maybe you downloaded the metadata from the needsign repo > >> before/during a push and the package for deleted when yum tried to > >> download it. Well, something like that probably. > >> > > I just retry and still have this problem : > > $ mock -r fedora-4-i386-epel drgeo-1.1.0-6.el4.src.rpm > > init > > clean > > prep > > This may take a while > > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Sun, 20 May 2007 18:19:13 GMT > > Server: Apache/2.0.52 > > Content-Length: 342 > > Connection: close > > Content-Type: text/html; charset=iso-8859-1 > > > > Trying other mirror. > > Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] > > No more mirrors to try. > > > > Error performing yum command: /usr/sbin/mock-helper yum > > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > > ending > > done > > Is there a proxy between you and the internet? It might fool you. > > Whatever: this is definitely no problem in the EPEL mock configs. You > can temporary work around it by disabling the needsign repo. > No i have direct connection to internet. Disabling the needsign repo seems to solve the problem but i can't understand where the problem come from and i will have problem when i will try to mock another package which need another one in needsign repo Here is the cfg file i use : #!/usr/bin/python -tt import os config_opts['root'] = 'epel-4-i386' config_opts['target_arch'] = 'i386' config_opts['yum.conf'] = """ [main] cachdir=/var/cache/yum debuglevel=1 logfile=/var/log/yum.log reposdir=/dev/null retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 # repos [core] name=base mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=os #baseurl=http://mirror.pacific.net.au/linux/CentOS/4.4/os/i386/ [update] name=updates mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=updates #baseurl=http://mirror.pacific.net.au/linux/CentOS/4.4/updates/i386/ [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ [extras] name=epel mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 #baseurl=http://download.fedora.redhat.com/pub/epel/4/i386/ #[local] #name=local #baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ """ From dag at wieers.com Sun May 20 18:49:30 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 20 May 2007 20:49:30 +0200 (CEST) Subject: repotags proposal In-Reply-To: <46509661.5070305@leemhuis.info> References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> <46509661.5070305@leemhuis.info> Message-ID: On Sun, 20 May 2007, Thorsten Leemhuis wrote: > On 20.05.2007 20:23, Stephen John Smoogen wrote: > > Could we please cut the animosity here. [...] > > Sorry, apart from maybe one mail in this sub-thread I found this > discussion fruitful to understand each others points. And I agree with Thorsten. Please try to live with my sarcasm, since I do want to shake hands at LinuxTag without hard feelings ! :) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From smooge at gmail.com Sun May 20 18:46:46 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 20 May 2007 12:46:46 -0600 Subject: repotags proposal In-Reply-To: <46509661.5070305@leemhuis.info> References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> <46509661.5070305@leemhuis.info> Message-ID: <80d7e4090705201146hb640070q35d8af3ed1864c85@mail.gmail.com> On 5/20/07, Thorsten Leemhuis wrote: > > > On 20.05.2007 20:23, Stephen John Smoogen wrote: > > Could we please cut the animosity here. [...] > > Sorry, apart from maybe one mail in this sub-thread I found this > discussion fruitful to understand each others points. > My comment was meant for about all of the current discussions. They all seem to be about everyone yelling about who is king of the package pile without much constructive talk. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sheltren at cs.ucsb.edu Sun May 20 23:29:02 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 20 May 2007 19:29:02 -0400 Subject: repotags proposal In-Reply-To: <465051FB.3030604@leemhuis.info> References: <465051FB.3030604@leemhuis.info> Message-ID: <99B5637F-ADBE-4406-9B92-2CC255616890@cs.ucsb.edu> On May 20, 2007, at 9:49 AM, Thorsten Leemhuis wrote: > > The EPEL Steering Committee gives this agreement only as long as > following points are meet by the technical solution: > > * it must remain possible to simply copy spec files between Fedora > and > EPEL branches without modifications > > * no hacks to the buildsys or modifications to the rpms after their > initial creation > > * the repotag must be used my all packages > > * no abuse of the disttag > Hi Thorsten, thanks for the proposal. I think that using some macro, such as %{?repotag}, or even just %{?repo} would be a good start. It is very easy to implement, and the same specs could still be used in Fedora without any problems (AFAICS). Adding it to the dist tag does not make sense to me. However, I am curious to know why you are against some sort of patch to the build system? It seems that could also be a nice possible solution. Aside from my question about having the build system handle the repotag on its own, I am mostly +1 for your proposal. -Jeff From mastahnke at gmail.com Mon May 21 01:23:47 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sun, 20 May 2007 20:23:47 -0500 Subject: repotags proposal In-Reply-To: <99B5637F-ADBE-4406-9B92-2CC255616890@cs.ucsb.edu> References: <465051FB.3030604@leemhuis.info> <99B5637F-ADBE-4406-9B92-2CC255616890@cs.ucsb.edu> Message-ID: <7874d9dd0705201823kcf7f5e4v6bfd8624ba06612f@mail.gmail.com> On 5/20/07, Jeff Sheltren wrote: > On May 20, 2007, at 9:49 AM, Thorsten Leemhuis wrote: > > > > The EPEL Steering Committee gives this agreement only as long as > > following points are meet by the technical solution: > > > > * it must remain possible to simply copy spec files between Fedora > > and > > EPEL branches without modifications > > > > * no hacks to the buildsys or modifications to the rpms after their > > initial creation > > > > * the repotag must be used my all packages > > > > * no abuse of the disttag > > > > Hi Thorsten, thanks for the proposal. I think that using some macro, > such as %{?repotag}, or even just %{?repo} would be a good start. It > is very easy to implement, and the same specs could still be used in > Fedora without any problems (AFAICS). Adding it to the dist tag does > not make sense to me. However, I am curious to know why you are > against some sort of patch to the build system? It seems that could > also be a nice possible solution. > > Aside from my question about having the build system handle the > repotag on its own, I am mostly > +1 for your proposal. Allow me to add a +1 for discussion of this. Working in an enterprise where Admins sometimes pull packages from a variety of sources, having a repo-tag helps me. I can figure where someone pulled a package. Our internally built packages also have a repotag (abuse of %dist tag actually) but it can be seen easily. I understand how to query rpms for a repo, sadly, many admins/users I work with don't. For the good of the end-user in EL-land, I support a repo tag. The implementation, I hope, could be painless . If EPEL started using repotags, maybe it would drive yum/rpm developers to evaluate its value again and get the proper coding into the packaging products. This isn't about right or wrong, it's about moving in a positive direction for the consumers of EL and ultimately the new EPEL platform. stahnma > > -Jeff > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From buildsys at fedoraproject.org Mon May 21 03:25:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 20 May 2007 23:25:38 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-20 Message-ID: <20070521032538.DB8C1152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW bugzilla-3.0-1.el5 : Bug tracking system NEW perl-Affix-Infix2Postfix-0.03-1.el5 : Perl extension for converting from infix notation to postfix notation NEW perl-Image-Math-Constrain-1.01-1.el5 : Scaling math used in image size constraining (such as thumbnails) NEW php-pear-Net-Ping-2.4.1-2.el5 : Execute ping NEW php-pear-Net-Traceroute-0.21.1-2.el5 : Execute traceroute Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: bugzilla-3.0-1.el5 ------------------ * Fri May 18 2007 John Berninger - 3.0-1 - update to upstream version 3.0 - add new dependencies on mod_perl, perl-SOAP-Lite - refactor patch(es) to change paths for read-only /usr perl-Affix-Infix2Postfix-0.03-1.el5 ----------------------------------- * Mon Apr 02 2007 Steven Pritchard 0.03-1 - Specfile autogenerated by cpanspec 1.70. - Fix License. perl-Image-Math-Constrain-1.01-1.el5 ------------------------------------ * Mon Apr 02 2007 Steven Pritchard 1.01-1 - Specfile autogenerated by cpanspec 1.70. - Drop redundant explicit perl build dependency. - Fix typo in description. - BR Test::Pod for better test coverage. php-pear-Net-Ping-2.4.1-2.el5 ----------------------------- * Wed May 16 2007 Remi Collet 2.4.1-2 - From review, correct typo. - add Requires: /bin/ping - add simple test in %check * Sat May 12 2007 Remi Collet 2.4.1-1 - initial RPM (generated specfile + cleanup) - add CHANGELOG and LICENSE - convert package.xml to package2.xml php-pear-Net-Traceroute-0.21.1-2.el5 ------------------------------------ * Wed May 16 2007 Remi Collet 0.21.1-2 - From review, change description - add Requires: traceroute * Sat May 12 2007 Remi Collet 0.21.1-1 - initial RPM (generated specfile + cleanup) - add CHANGELOG and LICENSE Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Mon May 21 04:44:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 21 May 2007 06:44:25 +0200 Subject: LinuxTAG (was Re: repotags proposal) In-Reply-To: References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> <46509661.5070305@leemhuis.info> Message-ID: <465123A9.1080601@leemhuis.info> On 20.05.2007 20:49, Dag Wieers wrote: > On Sun, 20 May 2007, Thorsten Leemhuis wrote: >> On 20.05.2007 20:23, Stephen John Smoogen wrote: > Please try to live with my sarcasm, since I > do want to shake hands at LinuxTag without hard feelings ! :) :-) LinuxTAG is a good catchword. I'll be there on Wednesday and Thursday -- if you want to meet me just look out for this men at the Fedora booth / on Fudcon: http://fedoraproject.org/wiki/ThorstenLeemhuis Cu thl From eric.tanguy at univ-nantes.fr Mon May 21 15:20:54 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 21 May 2007 17:20:54 +0200 Subject: Mock for EPEL In-Reply-To: <4650957B.5010705@leemhuis.info> References: <1179390704.11111.24.camel@bureau.maison> <464C19B4.20008@FamilleCollet.com> <464C1D6F.3050007@leemhuis.info> <1179394217.11111.26.camel@bureau.maison> <464C229F.2020503@leemhuis.info> <1179395467.11111.28.camel@bureau.maison> <464C2D57.9050903@leemhuis.info> <1179473506.11111.34.camel@bureau.maison> <1179684299.8858.0.camel@bureau.maison> <465090A5.9040305@leemhuis.info> <1179685196.8858.2.camel@bureau.maison> <4650957B.5010705@leemhuis.info> Message-ID: <1179760855.8858.16.camel@bureau.maison> Le dimanche 20 mai 2007 ? 20:37 +0200, Thorsten Leemhuis a ?crit : > On 20.05.2007 20:19, Tanguy Eric wrote: > > Le dimanche 20 mai 2007 ? 20:17 +0200, Thorsten Leemhuis a ?crit : > >> On 20.05.2007 20:04, Tanguy Eric wrote: > >>> No one can help me to undrestand why there is this problem ? > >> Try again, I confident the problem will be gone. It was likely bad > >> timing -- maybe you downloaded the metadata from the needsign repo > >> before/during a push and the package for deleted when yum tried to > >> download it. Well, something like that probably. > >> > > I just retry and still have this problem : > > $ mock -r fedora-4-i386-epel drgeo-1.1.0-6.el4.src.rpm > > init > > clean > > prep > > This may take a while > > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Sun, 20 May 2007 18:19:13 GMT > > Server: Apache/2.0.52 > > Content-Length: 342 > > Connection: close > > Content-Type: text/html; charset=iso-8859-1 > > > > Trying other mirror. > > Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] > > No more mirrors to try. > > > > Error performing yum command: /usr/sbin/mock-helper yum > > --installroot /var/lib/mock/epel-4-i386/root install buildsys-build > > ending > > done > > Is there a proxy between you and the internet? It might fool you. > > Whatever: this is definitely no problem in the EPEL mock configs. You > can temporary work around it by disabling the needsign repo. > This problem is also in the build system : http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log From eric.tanguy at univ-nantes.fr Mon May 21 16:03:45 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 21 May 2007 18:03:45 +0200 Subject: Build problem for EPEL-4 Message-ID: <1179763425.8858.19.camel@bureau.maison> I tried to build some packages for EL-4 and all fail due to the same error : http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log From smooge at gmail.com Mon May 21 22:00:07 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 21 May 2007 16:00:07 -0600 Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> <46506656.8060904@leemhuis.info> <46507230.1080509@leemhuis.info> <80d7e4090705201123s16160b89yc3ac40987d0fba7@mail.gmail.com> <46509661.5070305@leemhuis.info> Message-ID: <80d7e4090705211500n409af8eak3262be4736dc32f9@mail.gmail.com> On 5/20/07, Dag Wieers wrote: > On Sun, 20 May 2007, Thorsten Leemhuis wrote: > > > On 20.05.2007 20:23, Stephen John Smoogen wrote: > > > Could we please cut the animosity here. [...] > > > > Sorry, apart from maybe one mail in this sub-thread I found this > > discussion fruitful to understand each others points. > > And I agree with Thorsten. Please try to live with my sarcasm, since I > do want to shake hands at LinuxTag without hard feelings ! :) > My apologies, but I couldnt tell when people were being sarcastic or just plain angry. From someone who is just wanting to get a working cross repo somehow.. it seemed that everything had devolved into a cesspool of comments. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pmatilai at laiskiainen.org Tue May 22 06:53:17 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 22 May 2007 09:53:17 +0300 (EEST) Subject: repotags proposal In-Reply-To: <465051FB.3030604@leemhuis.info> References: <465051FB.3030604@leemhuis.info> Message-ID: On Sun, 20 May 2007, Thorsten Leemhuis wrote: > I wrote a quick proposal for repotags in EPEL. If people really want > repotags in EPEL please speak up in this thread -- I'd really like to > see that contributors really want repotags before I propose this > proposal for voting in a SIG meeting. [...] > That agreement if given for EL4 and EL5 only -- the EPEL Steering > Committee would like to see a technical solution that properly solves > the problem repotags are trying to solve currently. My 5c on the topic I've been trying to avoid because it's too flammable for my taste. I hate politics so I'm not going to get into that, I'm commenting from purely technical POV, and actually have a proposal that might make them unnecessary. Repotags as part of release string are just plain wrong. Unlike disttag, the repotag does not have a meaningful version information in it, it's really just a fuzz-factor to somehow differentiate packages coming from different places. The perfect repotag would actually be the package's gpg signature: - it's not involved in version comparison - it can't be faked by locally rebuilding a package - it's recorded in rpmdb so it's possible to see where a package came from For depsolvers, you need some sort of priorisation mechanism anyway to make any sense out of mixed repository situation. So the repotag mostly serves as a visual clue to humans. All the major depsolvers now have some means to priorize between repositories so what the actual rpm EVR string is doesn't really matter, what's missing is the visual clue. Now, I hereby volunteer to write a script/popt-alias/whatever that will do the necessary mapping of gpg signature into something human readable so people can diagnose their repo-mixing problems and whatnot easily. So you'd get something resembling the below: $ repotag -q foo bar foo-1.2-4.el5 (EPEL) bar-2.3-1.el5 (ATrpms) Would something like that be enough for the "repotag folks", short term? Long-term, more than that's needed to really solve the issues with repository mixing. One (perhaps crazy) idea is turning repotags into namespaces, and dependencies are first looked up within that namespace and only if unsolved, other namespaces are looked at in (configurable) order. An example (please excuse the :: notation, that's not a good choice but for examples sake...): assume we have packages foo and bar which both depend on glibc, and foo additionally depends on bar. Foo and bar are available from, say, both EPEL and ATrpms: rhel::libxml2-2.6.28-1 epel::foo-1.2-1 atrpms::foo-1.2-1 epel::bar-2.4-5 atrpms::bar-2.4-1 If you install atrpms::foo, as atrpms namespace also provides bar, that one gets selected instead of epel::bar even though it's evr is higher. The actual namespace could internally be the gpg signature, only mapped to a human readable where exposed to the user. Sound crazy enough? ;) - Panu - From cmc at math.hmc.edu Tue May 22 21:19:15 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Tue, 22 May 2007 14:19:15 -0700 Subject: Update strategy In-Reply-To: <464B3860.6020609@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4649D093.1090409@leemhuis.info> <80d7e4090705151413u170c483ah42d782ddc9d958cf@mail.gmail.com> <464B3860.6020609@leemhuis.info> Message-ID: <30177.1179868755@vosill.math.hmc.edu> "TL" == Thorsten Leemhuis "SJS" == Stephen John Smoogen SJS> The early adopters wanted RHEL-5 with additional items SJS> and some level of replacement. They wanted the newest SJS> version of say moin, clustering application etc as they SJS> are usually wanting the best new experience for their SJS> 'customers'... but want more stability in the SJS> backend. Most are served by a Fedora or the Red Hat SJS> Global Desktop.. but may need a core set of items SJS> (glibc/kernel) stable for some programmatic reason TL> I'd say those people that only want some new apps and a TL> stable backend are best served with a local repo for the TL> apps they need in up2date version or other specific small TL> repos. They can use the Fedora packages as a base for it; TL> EPEL probably can't serve those people with todays tools TL> (yum and co), as each and everyone defines stable backend TL> differently. That's about where we are right now. We're running CentOS on servers and workstations because it's easier to maintain a local set of packages for one OS (although we're currently spread out over 3 and 4, with 5 the obvious upgrade path for the summer). Our users don't need the latest and greatest cutting-edge software for most things, but it is important that some tools (math-related applications, TeX system, Subversion, etc.) be very recent. I do have my own local repo, mostly with packages from Fedora and Dag's RPMforge, and I expected that I would have to maintain that for some packages (including packages Fedora can't/won't touch because of licensing or patent issues but the users demand; packages for commercial software that we definitely couldn't distribute; and packages for software that may not be distributable because of its licensing terms). But I was really looking forward to having a single source for reasonably up-to-date packages for the packages that are in Fedora. From this discussion, it sounds like EPEL is targeting a completely different set of end users. Given the general political nastiness surrounding the whole repotags issue, it also sounds like there isn't much interest in cooperating with the other third-party repos, which makes EPEL a lot less attractive. I'm still watching, but I'm leaning toward deciding that EPEL isn't going to be worth bothering with. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From tla at rasmil.dk Wed May 23 07:35:10 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 23 May 2007 09:35:10 +0200 Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> Message-ID: <4653EEAE.5040304@rasmil.dk> Panu Matilainen wrote: > > My 5c on the topic I've been trying to avoid because it's too > flammable for my taste. I hate politics so I'm not going to get into > that, I'm commenting from purely technical POV, and actually have a > proposal that might make them unnecessary. > > Repotags as part of release string are just plain wrong. Unlike > disttag, the repotag does not have a meaningful version information in > it, it's really just a fuzz-factor to somehow differentiate packages > coming from different places. > > The perfect repotag would actually be the package's gpg signature: > - it's not involved in version comparison > - it can't be faked by locally rebuilding a package - it's recorded in > rpmdb so it's possible to see where a package came from > > For depsolvers, you need some sort of priorisation mechanism anyway to > make any sense out of mixed repository situation. So the repotag > mostly serves as a visual clue to humans. All the major depsolvers now > have some means to priorize between repositories so what the actual > rpm EVR string is doesn't really matter, what's missing is the visual > clue. > > Now, I hereby volunteer to write a script/popt-alias/whatever that > will do the necessary mapping of gpg signature into something human > readable so people can diagnose their repo-mixing problems and whatnot > easily. So you'd get something resembling the below: > > $ repotag -q foo bar > foo-1.2-4.el5 (EPEL) > bar-2.3-1.el5 (ATrpms) > > Would something like that be enough for the "repotag folks", short term? > Look like a great idea, do you plan to do at standalone tool or something based on the the Yum API, it sounds like a candidate to yum-utils. > Long-term, more than that's needed to really solve the issues with > repository mixing. One (perhaps crazy) idea is turning repotags into > namespaces, and dependencies are first looked up within that namespace > and only if unsolved, other namespaces are looked at in (configurable) > order. > > An example (please excuse the :: notation, that's not a good choice > but for examples sake...): assume we have packages foo and bar which > both depend on glibc, and foo additionally depends on bar. Foo and bar > are available from, say, both EPEL and ATrpms: > > rhel::libxml2-2.6.28-1 > epel::foo-1.2-1 > atrpms::foo-1.2-1 > epel::bar-2.4-5 > atrpms::bar-2.4-1 > > If you install atrpms::foo, as atrpms namespace also provides bar, > that one gets selected instead of epel::bar even though it's evr is > higher. The actual namespace could internally be the gpg signature, > only mapped to a human readable where exposed to the user. Sound crazy > enough? ;) Yes, i sounds very crazy to me ;-) ;-) . I dont know if this can be done without a lot of changes into RPM. Nice to see something constructive to solve the real problems. Tim From dag at wieers.com Wed May 23 12:43:45 2007 From: dag at wieers.com (Dag Wieers) Date: Wed, 23 May 2007 14:43:45 +0200 (CEST) Subject: repotags proposal In-Reply-To: <4653EEAE.5040304@rasmil.dk> References: <465051FB.3030604@leemhuis.info> <4653EEAE.5040304@rasmil.dk> Message-ID: On Wed, 23 May 2007, Tim Lauridsen wrote: > Panu Matilainen wrote: > > > My 5c on the topic I've been trying to avoid because it's too flammable for > > my taste. I hate politics so I'm not going to get into that, I'm commenting > > from purely technical POV, and actually have a proposal that might make them > > unnecessary. > > > > Repotags as part of release string are just plain wrong. Unlike disttag, the > > repotag does not have a meaningful version information in it, it's really > > just a fuzz-factor to somehow differentiate packages coming from different > > places. It does have meaningful version information in a multi-repository world. It shows what version of the package you have. rf means this is the RPMforge version. It makes the package/filename/version unique ! Granted, the repotag does not have any real meaning in "version comparison" between packages from different repositories. Neither does the release tag. The release tag has no meaningful version information between packages from different repositories. > > The perfect repotag would actually be the package's gpg signature: > > - it's not involved in version comparison > > - it can't be faked by locally rebuilding a package - it's recorded in rpmdb > > so it's possible to see where a package came from It is not a perfect repotag for other reasons: - It doesn't make the filename unique (or gives insight of the package before downloading) - It is not shown when one has dependency problems, either on yum, apt or rpm level > > For depsolvers, you need some sort of priorisation mechanism anyway to make > > any sense out of mixed repository situation. So the repotag mostly serves as > > a visual clue to humans. All the major depsolvers now have some means to > > priorize between repositories so what the actual rpm EVR string is doesn't > > really matter, what's missing is the visual clue. The major depsolvers lack a meaningful way for a user to provide a policy of what they want to do with repositories or packages. Some plugins do allow somewhat more, but there are many shortcomings and without repotags errors are at first sight inexplicable or confusing. Especially when packages from different repositories have the same NEVR, similar sub-packages and have dependencies between them. The clamav package is a nice example. Without repotags, dependencies would exists between packages from different repositories. Saying that repotags have no meaningful version information is very wrong. It makes the system work. > > Now, I hereby volunteer to write a script/popt-alias/whatever that will do > > the necessary mapping of gpg signature into something human readable so > > people can diagnose their repo-mixing problems and whatnot easily. So you'd > > get something resembling the below: > > > > $ repotag -q foo bar > > foo-1.2-4.el5 (EPEL) > > bar-2.3-1.el5 (ATrpms) > > > > Would something like that be enough for the "repotag folks", short term? > > Look like a great idea, do you plan to do at standalone tool or something > based on the the Yum API, it sounds like a candidate to > yum-utils. It doesn't help for dependency problems. In this case it shows what a working rpmdb consists of. Necessary, but not sufficient to replace a repotag implementation as it is. > > Long-term, more than that's needed to really solve the issues with > > repository mixing. One (perhaps crazy) idea is turning repotags into > > namespaces, and dependencies are first looked up within that namespace and > > only if unsolved, other namespaces are looked at in (configurable) order. > > > > An example (please excuse the :: notation, that's not a good choice but for > > examples sake...): assume we have packages foo and bar which both depend on > > glibc, and foo additionally depends on bar. Foo and bar are available from, > > say, both EPEL and ATrpms: > > > > rhel::libxml2-2.6.28-1 > > epel::foo-1.2-1 > > atrpms::foo-1.2-1 > > epel::bar-2.4-5 > > atrpms::bar-2.4-1 > > > > If you install atrpms::foo, as atrpms namespace also provides bar, that one > > gets selected instead of epel::bar even though it's evr is higher. The > > actual namespace could internally be the gpg signature, only mapped to a > > human readable where exposed to the user. Sound crazy enough? ;) > > Yes, i sounds very crazy to me ;-) ;-) . > I dont know if this can be done without a lot of changes into RPM. The namespace idea is an interesting one and when it gets implemented and is ready is surely an alternative to repotags. But it is not ready and will not be in EL2.1, EL3, EL4 or EL5. So we cannot consider it an alternative because we cannot use it now. It's not that I'm unwilling to see an alternative, it's just that there is NO alternative to repotags that cover it's different uses. > Nice to see something constructive to solve the real problems. It doesn't solve real problems as it is not a realistic solution yet. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Wed May 23 12:56:06 2007 From: dag at wieers.com (Dag Wieers) Date: Wed, 23 May 2007 14:56:06 +0200 (CEST) Subject: Repotags do have meaningful version information (was: repotags proposal) In-Reply-To: References: <465051FB.3030604@leemhuis.info> <4653EEAE.5040304@rasmil.dk> Message-ID: On Wed, 23 May 2007, Dag Wieers wrote: > On Wed, 23 May 2007, Tim Lauridsen wrote: > > Panu Matilainen wrote: > > > > > My 5c on the topic I've been trying to avoid because it's too flammable for > > > my taste. I hate politics so I'm not going to get into that, I'm commenting > > > from purely technical POV, and actually have a proposal that might make them > > > unnecessary. > > > > > > Repotags as part of release string are just plain wrong. Unlike disttag, the > > > repotag does not have a meaningful version information in it, it's really > > > just a fuzz-factor to somehow differentiate packages coming from different > > > places. > > It does have meaningful version information in a multi-repository world. > It shows what version of the package you have. rf means this is the > RPMforge version. It makes the package/filename/version unique ! -snip- > Especially when packages from different repositories have the same NEVR, > similar sub-packages and have dependencies between them. > > The clamav package is a nice example. Without repotags, dependencies would > exists between packages from different repositories. > > Saying that repotags have no meaningful version information is very wrong. > It makes the system work. For everybody involved, please read the above again. Most people object to repotags because the repotag does not have any use in the version comparison. That's right, it does not. But it *does* affect dependencies when there is no identifier in the version/release information. Particularly when there is more than one repository. So it is indisputable that it is meaningful in the version information, because without it RPM would fail to resolve dependencies in a correct way. This was brought up at least 3 times in the previous discusisons. You see why it is frustrating when people keep on objecting but loose half of the information that was provided. Why we have to repeat. Why Axel gets tired. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From pmatilai at laiskiainen.org Thu May 24 12:53:30 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 24 May 2007 15:53:30 +0300 (EEST) Subject: Repotags do have meaningful version information (was: repotags proposal) In-Reply-To: References: <465051FB.3030604@leemhuis.info> <4653EEAE.5040304@rasmil.dk> Message-ID: On Wed, 23 May 2007, Dag Wieers wrote: > On Wed, 23 May 2007, Dag Wieers wrote: > >> On Wed, 23 May 2007, Tim Lauridsen wrote: >>> Panu Matilainen wrote: >>> >>>> My 5c on the topic I've been trying to avoid because it's too flammable for >>>> my taste. I hate politics so I'm not going to get into that, I'm commenting >>>> from purely technical POV, and actually have a proposal that might make them >>>> unnecessary. >>>> >>>> Repotags as part of release string are just plain wrong. Unlike disttag, the >>>> repotag does not have a meaningful version information in it, it's really >>>> just a fuzz-factor to somehow differentiate packages coming from different >>>> places. >> >> It does have meaningful version information in a multi-repository world. >> It shows what version of the package you have. rf means this is the >> RPMforge version. It makes the package/filename/version unique ! > > -snip- > >> Especially when packages from different repositories have the same NEVR, >> similar sub-packages and have dependencies between them. >> >> The clamav package is a nice example. Without repotags, dependencies would >> exists between packages from different repositories. >> >> Saying that repotags have no meaningful version information is very wrong. >> It makes the system work. > > For everybody involved, please read the above again. > > Most people object to repotags because the repotag does not have any use > in the version comparison. That's right, it does not. > > But it *does* affect dependencies when there is no identifier in the > version/release information. Particularly when there is more than one > repository. > > So it is indisputable that it is meaningful in the version information, > because without it RPM would fail to resolve dependencies in a correct > way. Ah, a good point which I didn't think of at all, sorry about that. I was only talking about version information in the "newer/older than another package of same name" sense. Yes, repotag-in-release allows sub-package dependencies to be expressed in a way that prevents accidental mixing of sub-packages of same name from other repositories. It would be of course possible to express that by using additional virtual provides-requires pairs but that adds a fair bit of manual work for little or no gain. Repository namespaces would help :) But the root issue here I think is that sub-packages often should and could have a stronger dependencies on each other than the typical "Requires: %{name} = %{version}-%{release}". In other words, one would want the sub-package dependency to only match packages originating from the same *build*. Something like "Requires: %{name} = %{buildid}" where the build id is a hash computed from version, release, arch, buildhost, buildtime plus possibly bunch of other things, and automatically injected into provides. > This was brought up at least 3 times in the previous discusisons. You see > why it is frustrating when people keep on objecting but loose half of the > information that was provided. Why we have to repeat. Why Axel gets tired. It's just that the actual issues tend to get lost in all the noise. At least I haven't had the stamina to read through all of the repotag discussions, because the "to repotag or not to repotag" question itself is totally irrelevant and uninteresting to me. The actual problems, not the bandaid, is what I'm interested in. - Panu - From pmatilai at laiskiainen.org Thu May 24 13:52:58 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 24 May 2007 16:52:58 +0300 (EEST) Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> <4653EEAE.5040304@rasmil.dk> Message-ID: On Wed, 23 May 2007, Dag Wieers wrote: > On Wed, 23 May 2007, Tim Lauridsen wrote: > >> Panu Matilainen wrote: >> >>> My 5c on the topic I've been trying to avoid because it's too flammable for >>> my taste. I hate politics so I'm not going to get into that, I'm commenting >>> from purely technical POV, and actually have a proposal that might make them >>> unnecessary. >>> >>> Repotags as part of release string are just plain wrong. Unlike disttag, the >>> repotag does not have a meaningful version information in it, it's really >>> just a fuzz-factor to somehow differentiate packages coming from different >>> places. > > It does have meaningful version information in a multi-repository world. > It shows what version of the package you have. rf means this is the > RPMforge version. It makes the package/filename/version unique ! Actually you could make the package filename contain a repotag just by tweaking %_build_name_fmt macro on the buildsystem. The packages themselves have plenty of uniquely identifying data in them, strongest of which is the signature (if present). It's just that the current tools dont allow using the data to full extent. > Granted, the repotag does not have any real meaning in "version > comparison" between packages from different repositories. Neither does the > release tag. The release tag has no meaningful version information between > packages from different repositories. Indeed (in the "is another package newer" sense) - like you noted it does have a meaning in non-automatic, versioned (sub-)package dependencies. >>> The perfect repotag would actually be the package's gpg signature: >>> - it's not involved in version comparison >>> - it can't be faked by locally rebuilding a package - it's recorded in rpmdb >>> so it's possible to see where a package came from > > It is not a perfect repotag for other reasons: > - It doesn't make the filename unique (or gives insight of the package > before downloading) > - It is not shown when one has dependency problems, either on yum, apt or > rpm level See above, filename "uniqueness" is easily solvable. Making a human-friendly signature visible in the tools obviously requires some modifications to the tools. So it might not help RHEL 2.1 or Fedora 7, but I'd rather try and start fixing the problems so I don't have to read about repotag arguments five years from now. >>> For depsolvers, you need some sort of priorisation mechanism anyway to make >>> any sense out of mixed repository situation. So the repotag mostly serves as >>> a visual clue to humans. All the major depsolvers now have some means to >>> priorize between repositories so what the actual rpm EVR string is doesn't >>> really matter, what's missing is the visual clue. > > The major depsolvers lack a meaningful way for a user to provide a policy > of what they want to do with repositories or packages. Some plugins do > allow somewhat more, but there are many shortcomings and without repotags > errors are at first sight inexplicable or confusing. > > Especially when packages from different repositories have the same NEVR, > similar sub-packages and have dependencies between them. > > The clamav package is a nice example. Without repotags, dependencies would > exists between packages from different repositories. Yup. See my other mail for an idea wrt this. Again, wont help you for existing releases. But that's just part of the problem... manual, versioned dependencies are a minority in the package dependency data, the vast majority is automatically generated soname dependencies where there are no repotags and things can (and do) get pretty mixed up easily. It might help if yum etc could try to first resolve dependencies from the same repo where the dependency itself comes from. > Saying that repotags have no meaningful version information is very wrong. > It makes the system work. "Prevents the system from totally blowing up" would be closer to reality I think :) >>> Now, I hereby volunteer to write a script/popt-alias/whatever that will do >>> the necessary mapping of gpg signature into something human readable so >>> people can diagnose their repo-mixing problems and whatnot easily. So you'd >>> get something resembling the below: >>> >>> $ repotag -q foo bar >>> foo-1.2-4.el5 (EPEL) >>> bar-2.3-1.el5 (ATrpms) >>> >>> Would something like that be enough for the "repotag folks", short term? >> >> Look like a great idea, do you plan to do at standalone tool or something >> based on the the Yum API, it sounds like a candidate to >> yum-utils. > > It doesn't help for dependency problems. In this case it shows what a > working rpmdb consists of. Necessary, but not sufficient to replace a > repotag implementation as it is. Right. >>> Long-term, more than that's needed to really solve the issues with >>> repository mixing. One (perhaps crazy) idea is turning repotags into >>> namespaces, and dependencies are first looked up within that namespace and >>> only if unsolved, other namespaces are looked at in (configurable) order. >>> >>> An example (please excuse the :: notation, that's not a good choice but for >>> examples sake...): assume we have packages foo and bar which both depend on >>> glibc, and foo additionally depends on bar. Foo and bar are available from, >>> say, both EPEL and ATrpms: >>> >>> rhel::libxml2-2.6.28-1 >>> epel::foo-1.2-1 >>> atrpms::foo-1.2-1 >>> epel::bar-2.4-5 >>> atrpms::bar-2.4-1 >>> >>> If you install atrpms::foo, as atrpms namespace also provides bar, that one >>> gets selected instead of epel::bar even though it's evr is higher. The >>> actual namespace could internally be the gpg signature, only mapped to a >>> human readable where exposed to the user. Sound crazy enough? ;) >> >> Yes, i sounds very crazy to me ;-) ;-) . >> I dont know if this can be done without a lot of changes into RPM. > > The namespace idea is an interesting one and when it gets implemented and > is ready is surely an alternative to repotags. > > But it is not ready and will not be in EL2.1, EL3, EL4 or EL5. So we > cannot consider it an alternative because we cannot use it now. > > It's not that I'm unwilling to see an alternative, it's just that there is > NO alternative to repotags that cover it's different uses. > >> Nice to see something constructive to solve the real problems. > > It doesn't solve real problems as it is not a realistic solution yet. Yes, I don't have a solution, but repotags are not a solution either, just a bandaid. I'd rather attempt to have a constructive discussion how to solve the bleeping problems for good. But this isn't the best forum for that discussion, going crazy with package/dependency namespaces and whatnot concerns far more people than are involved in epel... - Panu - From fedora at leemhuis.info Thu May 24 15:48:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 24 May 2007 17:48:23 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting Message-ID: <4655B3C7.4070002@leemhuis.info> 00:00 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00 < knurd> | Hi everybody; who's around? 00:00 * | nirik is here. 00:00 < knurd> | sorry, I forgot to send the list of topics out 00:01 < knurd> | I was busy with preparation for my FUDCon/Linuxtag talk 00:01 < stahnma> | ack 00:01 < > | listening in 00:01 * | mmcgrath is here 00:01 < LetoTo> | I'm around 00:01 --> | Jeff_S (Jeff Sheltren) has joined #fedora-meeting 00:02 < Jeff_S> | Hi 00:02 < knurd> | hmmmm 00:02 < knurd> | makes four people from the steeing committee afaics 00:02 < knurd> | so let's start 00:02 < stahnma> | do we have topics? 00:02 < knurd> | stahnma, http://fedoraproject.org/wiki/EPEL/Schedule 00:02 < knurd> | they are always in the meeting 00:02 < stahnma> | always a good start :) 00:03 < knurd> | everyone can add someting there if he likes to 00:03 --- | knurd has changed the topic to: EPEL Meeting -- repotags/interaction with 3rd party repos -- owner: all 00:03 < knurd> | well, the same old topic again 00:03 < knurd> | I'm still unsure myself what to do 00:03 < knurd> | put feed down? 00:03 * | mmcgrath notes that this is not a destination but a journey. 00:03 < stahnma> | sure is 00:03 < knurd> | let someone work out repotag details with the FPC? 00:04 < mmcgrath> | I haven't followed the FPC's logs on this at all, do they care? 00:04 < stahnma> | details as in implementation or dtails has in figure out if we should use it? 00:04 < knurd> | mmcgrath, seems spot doesn't like them to much 00:05 < knurd> | stahnma, "details in implementation" 00:05 < knurd> | mmcgrath, thimm is for them 00:05 < nirik> | perhaps we should ask koji wizards how hard it would be to make it add a repotag for epel builds in the buildsys? 00:05 < knurd> | mmcgrath, f13 against repotags afaics 00:05 < mmcgrath> | but they at least care enough to discuss it further? 00:05 < mmcgrath> | They won't just dismiss it? 00:05 < knurd> | mmcgrath, not sure 00:05 < mmcgrath> | 00:05 < knurd> | mmcgrath, last time I asked I got a " write a proposal first" reply 00:05 < stahnma> | IIRC, if EPEL says yes, they won't overrule us 00:06 < nirik> | I don't like them, but dag, thimm, planetccrm, etc are all mad... if it will make them happy and we can do it some way easily I would do it just to make them all happy. 00:06 < stahnma> | else, they are not going to pursue it theirselves 00:06 < nirik> | at least then the topic would hopefully go away. 00:06 < knurd> | nirik, hopefully 00:07 < knurd> | so shall we vote on https://www.redhat.com/archives/epel-devel-list/2007-May/msg00105.html ? 00:07 < knurd> | minus the " * no hacks to the buildsys or modifications to the rpms after their 00:07 < knurd> | initial creation" 00:07 < stahnma> | I think we need the 3rd repos onboard for EPEL to be sucessful, so an implemetnation shoudl be looked at 00:07 < stahnma> | knurd: should we get hte buildsys questions answered before a vote? 00:07 < nirik> | yeah, that proposal as written isn't possible I don;'t think./ 00:08 < Jeff_S> | knurd: I think that either adding a %{?repo} tag, or modifying the build system to add it to EPEL packages is the way to go 00:08 < knurd> | stahnma, there are lots of questions that would need to be answered 00:08 < stahnma> | if we know the buildsys changes/requirements, I think the vote will make more sense 00:08 < nirik> | I think the only easy/possible solution is the buildsys overriding to add the tag. 00:08 < knurd> | stahnma, someone just needs to work out everything 00:08 < f13> | to do that you need a package in the buildroot to either define a further macro, or redefine the %{?dist} macro 00:08 < f13> | and then you need to have support for it in the Makefile.common stuff, for your branch. 00:08 * | abadger1999 heard FPC and looks in. 00:09 < knurd> | well, so what to do 00:09 < nirik> | right. dist won't get everything tho... 00:09 < f13> | and since we're making %{?dist} tags locally resolvable, having a different %{?dist} value than RHEL is going to be... interesting. 00:09 < knurd> | simply say "we want repotags, FPC please tell us how"? 00:09 < knurd> | f13, I don#t like abusing dist 00:09 < knurd> | f13, it's optional 00:09 < quaid> | sorry, I have to take dd to the dentist, running 'twixt appointments right now 00:09 < stahnma> | could we modify universally to use %{?repo} and have Fedora just have it blank? 00:10 < f13> | %{?dist} is defined in redhat-rpm-config forward moving, perhaps in RHEL5.1 00:10 < Jeff_S> | well surely there are more ways to do it in the buildsys than using %dist 00:10 * | quaid is absent officially now and will catch up via buffer later 00:10 < knurd> | stahnma, yes, that's what I proposed on fedora-devel 00:10 < nirik> | but that requires fedora to have a useless tag... :( 00:10 < Jeff_S> | stahnma: I agree, why not propose using %{?repo} 00:11 < stahnma> | I thought that great came from somewhere :) 00:11 --- | rdieter_away is now known as rdieter 00:11 < Jeff_S> | stahnma: not useless... unused :) 00:11 < stahnma> | great idea even 00:11 < knurd> | well, so what to do? 00:11 < knurd> | shall we approve a kind of 00:12 < nirik> | also would result in a lot of checkins on fedora to just keep things in sync with epel... ;( 00:12 < knurd> | "EPEL wants considers to use repotags; FPC please work out a solution" ? 00:12 < stahnma> | we need someone with buildsys experience to probably work on the tech details. If it's a vote to move forward in persuit of the repotag, that's fine 00:12 < knurd> | stahnma, we need someone to driver the whole repotags thing 00:12 < knurd> | that will be a lot of work 00:12 < f13> | 'wants to consider' um no. 00:12 < knurd> | and I'm not volunteering 00:12 < f13> | make up your mind before we spend time/effort making it happen. 00:13 <-- | nim-nim has quit ("Leaving.") 00:13 < knurd> | f13, I'm don#t want to give a blanket approved without knowing how therepotag will be realized 00:13 < nirik> | bit of a chicken/egg thing there... 00:13 < f13> | but that's purely details. Either you want a repo tag or not. 00:13 < knurd> | f13, you in my position would do the same 00:13 < knurd> | I would assume 00:13 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:13 < f13> | if you want a tag, say so. THen when FPC or whomever comes up with a way to realize it, you can say yay or nay on said implimentation. 00:13 < knurd> | nirik, that's why I wrote https://www.redhat.com/archives/epel-devel-list/2007-May/msg00105.html 00:13 < rdieter> | knurd: imo, epel's job here is simple: policy, yes/no. 00:14 < f13> | rdieter: +1 00:14 < nirik> | right. 00:14 < knurd> | f13, well, if we can still say "no" after FPC worked something out then that's fine with me 00:14 < stahnma> | ok 00:14 < stahnma> | so epel approves policy, next step is to infrastructure/FPC on implementation? 00:15 < f13> | knurd: that's fine, that's just color of the bike shed. 00:15 < f13> | knurd: first you ahve to figure out if you even want a bike shed. 00:15 < knurd> | f13, we want a bike shed afaics 00:15 < stahnma> | ok, sounds like a plan 00:15 < knurd> | but if the bike shed looks bad later I want to say "no" 00:15 < f13> | epel passed a vote? 00:15 < knurd> | or I want to give you some rough plans 00:15 < knurd> | f13, not yet 00:15 < nirik> | yeah. I dislike repotags, but its never going to go away until we do it, and it will make other repos happier with us. 00:15 * | mmcgrath thinks we have more important things to do 00:16 < f13> | I hate the idea and I'll refuse to allow them be used anywhere that I have control over. 00:16 < knurd> | I would only want them for EL4 and EL5 00:16 < f13> | but thankfully for you, I dn't have any control here (: 00:16 < Jeff_S> | f13: care to elaborate? 00:16 < knurd> | rediscuss by EL6 00:16 --> | nim-nim (Nicolas Mailhot) has joined #fedora-meeting 00:16 < mmcgrath> | nirik: I'm questioning how important that is. 00:17 < mmcgrath> | nirik: after all, none of those people are even here right now. 00:17 < nirik> | yeah, I don't know. I would prefer to cooperate, but I suspect after we do repotags there will be a next thing after that... so not sure how far it will really get us... 00:17 < f13> | Jeff_S: on the whole they're pointless, they add cruft to systems, they provide little to no intrinsic value, they're easily "fakeable", and it's the wrong solution to the problem. 00:17 * | knurd afk for two minutes -- sorry 00:17 < nirik> | but I am willing to try it and see... 00:18 < stahnma> | I think they provide value to end-users/admins...even if it is <100% reliable 00:18 < f13> | and if the other repos are bitching, because our packages won't have a tag, well that makes it pretty easy to see which are our packages and which are they're packages. 00:18 < f13> | they're packages have a repo tag, end of story. 00:18 < nirik> | the only advantage they have is that other repos find that they help identify what repo a package came from in problem reports. 00:18 < Jeff_S> | f13: what's "the problem" in your opinion, and have other/better solutions been proposed? 00:18 < f13> | stahnma: there are 100% reliable methods to get same value, and there is low hanging fruit to make that info even more accessable. 00:19 < f13> | Jeff_S: use gpg key. Use builder information. Use Distributor. 00:19 < stahnma> | teach rookies to use GPG 00:19 < nirik> | but they claim their end users are not able to do that. 00:19 < stahnma> | then get back to me 00:19 < mmcgrath> | AFAIK the root 'problem' is package conflicts. And repo tag does not fix that. 00:19 < f13> | stahnma: they don't need to know how to use gpg. 00:19 < f13> | stahnma: they need to know how to use rpm -qi 00:19 < nirik> | doesn't fix it, but helps identify what repo the problem is in... or related to at least 00:20 < f13> | and I don't know why EPEL is worked up over working togehter with repos we can't even mention due to legal difficulties. 00:21 --> | kital (Joerg Simon) has joined #fedora-meeting 00:21 < nirik> | note that it looks like thimm has dropped repotags from atrpms already. 00:22 < Jeff_S> | f13: I think in general EPEL would like to form a community w/ other packagers whether or not RH can mention them. It seems like Repo tags in EPEL would help bridge the gap there 00:22 < nirik> | http://lists.atrpms.net/pipermail/atrpms-devel/2007-April/001508.html 00:23 < stahnma> | it is a step of good-faith toward the other repos that have the EL add-on community thus far. 00:23 < mmcgrath> | nirik: that email seems to indicate to me that this is a completely political issue. one that has done nothing but distract us. 00:24 * | mmcgrath notes thimm is used to running a repo where his rule is law. 00:24 < f13> | Jeff_S: but if EPEL wants all software avialble to users, all said software has to be in EPEL, which really obsolets the other repos. 00:24 < mmcgrath> | Its probably difficult to go from that to an environment like EPEL. 00:24 < f13> | Jeff_S: 'form a community' should more be 'make EPEL more compelling to work in than doing your own thing'. 00:24 < nirik> | http://lists.rpmforge.net/pipermail/packagers/2007-April/000316.html also for rpmforge 00:25 < Jeff_S> | f13: well, however you feel like phrasing it. getting more people to work together IMO is a good goal to have 00:25 < rdieter> | f13: that's a bad attitude (EPEL obsoletes all), best to be avoided (no matter how close to the truth it really is). 00:25 < Jeff_S> | f13: why would EPEL need to obsolete other repos? 00:25 < mmcgrath> | Jeff_S: what if getting more people means talking about one issue for months on end when 'more people' means 3 or 4 people? 00:25 < Jeff_S> | there are many things EPEL won't ever have due to licensing, etc 00:26 < Jeff_S> | well if 3 or 4 people are building hundreds of pkgs, that seems good to me 00:26 < mmcgrath> | none of whom care about epel enough to be here. 00:26 < rdieter> | mmcgrath: and they never will, unless consessions are made in good faith. 00:26 < mmcgrath> | rdieter: I'd argue that even if this consession was made they wouldn't participate. 00:27 < mmcgrath> | hell, thimm was the closest person and he does not have a single epel package. 00:27 < rdieter> | maybe... but the risk/reward is positive, imo. 00:27 < stahnma> | I think he was waiting for the official decision on repotags and the opening of the repo 00:27 < f13> | Jeff_S: If Red Hat wants to promote EPEL as being the place to get addon packages to RHEL, EPEL should have all the packages one would want, IE all the free and opensource and legal packages. 00:28 < f13> | Jeff_S: Red Hat can't say "oh, but that package isn't in EPEL, you have to go to to get that free and legal package" because is a place that houses illegal packages. 00:28 < mmcgrath> | I just want to get something done. we've been talking about this issue since march. We've been talking about it for a half hour already in this meeting. 00:28 < f13> | for EPEL to be successful as a place to get packages and promoted by Red Hat like Fedora Extras was, the software must be available in EPEL. 00:28 < rdieter> | mmcgrath: +1 (vote) 00:28 < nirik> | mmcgrath: +999 00:28 < mmcgrath> | and not one person here is actually in favor of repo tags. There's just people in favor of working with other people who aren't part of our community who are in favor of repo tags. 00:28 < mmcgrath> | and thats very telling. 00:29 < nirik> | after reading that rpmforge and atrpms have already dropped the repotag, I think we shouldn't bother to try and add it... 00:29 < f13> | rdieter: bad attitude or not, I deal in truths when possible. 00:29 < Jeff_S> | I don't deal directly w/ end user support for Fedora/EL, but from everything I hear from people that do, repotags would be very helpful for them. That makes me in favor of them... 00:29 < f13> | it's the same reason why Fedora Extras really obsoleted other repos aside from the illegal stuff. 00:30 < f13> | Jeff_S: I don't buy it. I've delt in end user support. THat argument is just a failling in the person providing the support to ask the right question, ie rpm -qi 00:30 < rdieter> | f13: that same attitude pushed potential contributors away in the beginning of FE, and I see history repeating itself... 00:30 < f13> | and since RHEL itself doesn't have a repo tag, this is all irrelevant. 00:31 < f13> | rdieter: explain to me how we can take advantage of packages only being available in a non Fedora repo that we can't mention due to legal reasons? 00:31 < f13> | rdieter: how is that any good to us? 00:31 < rdieter> | f13: those other repos include *lots* of legally ok stuff. 00:31 < rdieter> | esp rpmforge. 00:32 < f13> | while at the same time including illegal stuff thus tainting the entire repo 00:32 < f13> | which is why we can't ship a repo file for them in Fedora, why we can't mention them in our wiki, etc.. etc.. 00:32 < f13> | great end user value there. 00:32 < mmcgrath> | we really shouldn't discuss what they do with their repos... 00:32 < mmcgrath> | its their repo. 00:32 < rdieter> | f13: you're getting offtopic (unless I'm missing something). ?? 00:33 < mmcgrath> | working with the other repos is about how we get the repos made, not so much whats in them. 00:33 < f13> | I am off topic... sortof. 00:33 < nirik> | so what do we do here? vote again on repotags? (and add it as a standing line item in the meetings? :) 00:33 < mmcgrath> | nirik: would that be the 3rd vote on repo tags? 00:34 < nirik> | at least. 00:34 < f13> | I'm just failing to see the value in "working with" a set of repos that we can't mention, we can't guide users to, we can't preconfigure user's systems for, we can't expect users to magically discover that there is another repo they have to manually add to get access to potentially useful software, that we could just put in repos that we _can_ guide users to. 00:35 < f13> | unless "working with" involves helping htem get all software that _can_ be published through EPEL into EPEL. 00:35 < nirik> | I think the idea is not that we want to use their repo, it's that we want their experence/people to help us and join us... 00:35 < mmcgrath> | f13: the fact is other users like those repos. And if using them breaks the system, that makes Fedora look bad. It doesn't matter whether its right or not. 00:35 <-- | JSchmitt has quit (Read error: 113 (No route to host)) 00:35 < rdieter> | f13: it's not working with other repos at issue, but working with an existing community of packagers, who could be potential Fedora/epel contributors. 00:36 <-- | ivazquez has quit (Remote closed the connection) 00:37 < f13> | mmcgrath: so our new users just are SOL on software that is hidden away in repos we can't mention or preconfigure for them, we just have to hope that they somehow discover that there are other repos and that they're safe to use... 00:37 * | f13 stops contributing to conversation. 00:37 --> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:37 * | rdieter is done too (I think), goes back to the rabble seats with his popcorn. 00:37 --> | ivazquez (gaim) has joined #fedora-meeting 00:37 * | smooge gets out of work meetings 00:37 < mmcgrath> | f13: Beats me, some how I managed to find them and use them. 00:38 < mmcgrath> | can we just stop talking about this and hope it goes away? 00:38 < mmcgrath> | who's even driving this issue anymore? 00:38 < Jeff_S> | mmcgrath: you can hope, but I'm not sure that will help... 00:38 < mmcgrath> | I'll ask it this way. 00:38 * | nirik was for just giving in and adding repotag before this meeting, but after reading that the other repos have stopped using it, it seems pretty moot... 00:39 --> | nihed (Unknown) has joined #fedora-meeting 00:39 < mmcgrath> | If I removed this item from the schedule right now... who would bring it up next week? 00:39 < smooge> | I can say that the gpg signature items looks like a better yum plugin term to help repo people. 00:39 < mmcgrath> | I know my approach isn't very diplomatic but this has gotten silly. 00:40 <-- | llaumgui has quit (Remote closed the connection) 00:40 < mmcgrath> | we've spent 40 minuts talking about stuff that just doesn't matter that much and the people in question have already removed the tag. 00:40 < nirik> | mmcgrath: perhaps you could try it and see? :) 00:40 < nirik> | knurd: would you re-add it? 00:40 < mmcgrath> | I'm going to remove it and will seriously take no offense if someone adds it again. 00:40 < mmcgrath> | I just think we're talking about it because its there. 00:41 --- | mmcgrath has changed the topic to: EPEL Meeting -- vacant seat in the steering committee 00:42 * | mmcgrath wonders where knurd is 00:42 < mmcgrath> | we have a vacant seat available. 00:42 < nirik> | he was going to send some emails about that to interested people. 00:42 < mmcgrath> | did that get done or is it still a todo item? 00:42 < stahnma> | I think he emailed people 00:42 < stahnma> | got some repsonses 00:42 < stahnma> | like "if I have to" 00:42 < stahnma> | and "if no one else will" 00:42 < mmcgrath> | gotta love the support :) 00:43 < Jeff_S> | how would one volunteer for that...? 00:43 < Jeff_S> | rdieter: you are not interested? 00:43 < mmcgrath> | Jeff_S: Buhh, I guess you'd just need to make your intentions known. The epel list would be a good place. 00:43 < stahnma> | epel list is probably the best place 00:43 < Jeff_S> | mmcgrath: where's the epel list? 00:43 < stahnma> | or direct to knurd 00:43 < Jeff_S> | (that was a joke) :) 00:44 < stahnma> | without knurd responding, next topic? 00:44 < rdieter> | Jeff_S: intrigued, yes, but honestly, my plate is way full/overflowing as-is. 00:44 < nirik> | Jeff_S: https://www.redhat.com/mailman/listinfo/epel-devel-list 00:44 < Jeff_S> | sorry nirik, it was a bad attempt at humor ;) 00:44 < mmcgrath> | Well there doesn't appear to be much to discuss on that topic right now 00:44 < nirik> | next topic is for quaid, and he's gone. next topic++ ? 00:44 < Jeff_S> | rdieter: ok, just curios 00:44 < Jeff_S> | *curious* 00:44 < mmcgrath> | Jeff_S: bad humor? oh you'll fit right in ;-) 00:44 < rdieter> | np 00:45 < stahnma> | ha 00:45 --- | mmcgrath has changed the topic to: EPEL Meeting -- Investigate single RHEL subscription for EPEL maintainers -- quaid 00:45 < mmcgrath> | quaid: anything? 00:45 < Jeff_S> | lol 00:45 < stahnma> | I think quaid is AFK 00:45 < mmcgrath> | 00:45 --- | mmcgrath has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken 00:45 < mmcgrath> | lmacken: ping? 00:45 < stahnma> | I would love to have a a subscription to RHN to work with with RHEL 00:45 < stahnma> | (previous topic still) 00:45 < mmcgrath> | I know that luke has been putting some configs together to deploy bodhi on our production application cluster. 00:45 < stahnma> | like develop a script that converts EPEL to an RHN channel 00:45 * | f13 mutters something unsavory about RHEL management. 00:45 < smooge> | mmcgrath, what does it take to to take the empty seat? 00:45 < nirik> | we need to look at converting epel to koji. 00:46 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:46 < nirik> | who would be someone who could drive that? 00:46 < mmcgrath> | smooge: I don't think we have a hard fast rule, I guess the group would meet on it and say yay or nay? 00:46 < mmcgrath> | wait, should I topic change back to the RHEL subscriptions? 00:46 * | knurd is partly back 00:46 < knurd> | sorry, real life cam in between 00:47 < knurd> | sorry, sorry, sorry 00:47 --- | mmcgrath has changed the topic to: EPEL Meeting -- Investigate single RHEL subscription for EPEL maintainers -- quaid 00:47 < mmcgrath> | knurd: no worries. 00:47 < mmcgrath> | stahnma: Yeah, It would be nice to get some RHEL subscriptions for our EPEL people though I think quaid has quite a journey ahead of him first. 00:47 < smooge> | ok if this is not going to occur, what are the alternatives? And when can we put a line in the sand on it 00:47 < mmcgrath> | It may be easier once red hat can more easily realize the value of EPEL. 00:47 < knurd> | mmcgrath, +1 00:48 < knurd> | I don#t think this is high on out todo list 00:48 < mmcgrath> | smooge: are you talking about the RHEL subs? 00:48 < nirik> | yeah, might be nice, but not any kind of blocker. 00:48 < knurd> | might be nice, but using centos normally should be fine 00:48 < smooge> | yes 00:48 < smooge> | mmcgrath, yes 00:48 < mmcgrath> | one alternative I see is to setup a xen box that people can 'rent' or check out or whatever. 00:48 < stahnma> | well if RHN ever goes truely open source, then we can work on it that way :) 00:48 < mmcgrath> | its less desirable but something. 00:49 < mmcgrath> | we'll talk about this next time when quaid is around. 00:49 --- | mmcgrath has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken 00:49 < mmcgrath> | knurd: are you back enough to manage the meeting again or should I keep going? 00:49 < nirik> | right, so for bodhi, I think we need to convert epel to using koji. 00:49 < knurd> | mmcgrath, yeah, looks like it 00:49 < knurd> | nirik, would we be the testing bed? 00:50 < nirik> | who would be the one to drive that? dgilmore ? 00:50 < knurd> | dgilmore seems to have much work to do already 00:50 < f13> | there are some roadblocks to that. 00:50 < nirik> | knurd: bodhi currently is expecting to talk to koji... 00:50 < f13> | like koji modifications that would make the binaries used in the buildroots not publically available. 00:50 < mmcgrath> | nirik: there's some technical hurdles to getting epel in to koji right now :-/ 00:50 < nirik> | without bodhi we have no way to do updates-testing, etc that we want to do. 00:50 < nirik> | ugh. ;( 00:50 < f13> | as that would essentially be giving away RHEL binaries for free and silly RHEL management doens't like that idea one bit. 00:51 * | mmcgrath notes we should have just used the centos binaries... 00:51 < f13> | nor do they like the alternative of using CentOS binaries. 00:51 * | smooge whistles 00:51 < knurd> | mmcgrath, then we right now could not build for ppc 00:51 < mbonnet> | I think we could make the argument for using CentOS binaries. 00:51 < smooge> | is there a need for ppc? 00:51 < nirik> | ok, so can bodhi talk to plague? I know thats more on lmacken's plate. 00:51 < mmcgrath> | f13: Do 'they' like epel at all? 00:51 < mmcgrath> | :) 00:51 < f13> | mmcgrath: oh sure! they LOVE epel.... 00:51 < knurd> | smooge, it's IMHO just one of sevreal problems afaics 00:52 < mbonnet> | mmcgrath: "They" are all for EPEL 00:52 < f13> | (it gives them a place to say "no, we don't want to accept this new package in RHEL, go play in EPEL" 00:52 < mmcgrath> | well thats good at least we're on the radar. 00:52 --> | has joined #fedora-meeting 00:53 < stahnma> | who is they? 00:53 < mbonnet> | mmcgrath: actually, I think that's one of the reasons "they" want us to be using RHEL binaries...some assurance that EPEL packages work best on RHEL 00:53 < knurd> | mmcgrath, so, can this problems be fixed so RHEL binaries for the EPEL builders are not available for the public? 00:53 < nirik> | so how do we move forward then? see if lmacken can add plague support to bodhi? 00:53 < mmcgrath> | well regardless there's not much we can discuss on this untill bodhi gets used and the technical hurdle is fixed. 00:53 < smooge> | well your build options look to be : RHEL but locked down and hidden, CentOS but not admitting it, or SciLinux but not admitting it 00:53 < knurd> | nirik, we afaics must switch to koji sooner or later in any case afaics 00:53 < f13> | actually 00:53 < mmcgrath> | knurd: I'm sure it can its just a matter of how hard and who's got the time to do it. 00:53 < f13> | what is plague using right now? 00:54 < stahnma> | OH, there's unbreakable linux too 00:54 * | stahnma hides in the corner 00:54 < smooge> | We prefer to call it Unspeakable Linux Ryleh 00:54 < nirik> | f13: you mean what is epel using for pushing from plague? 00:54 < f13> | nirik: no, what is plague using ot build EPEL packages? 00:54 < mmcgrath> | f13: right now EPEL is identical to extras just built against RHEL 00:54 < f13> | so RHEL binaries? 00:54 < mmcgrath> | 00:54 < Jeff_S> | f13: yes 00:54 < nirik> | ah... I think dgilmore has a repo of rhel binaries. 00:54 < f13> | (signed and all that) 00:55 < f13> | but the repo is only reachable from plague builders? 00:55 * | knurd wondes why koji-mock exposed RHEL binaries to the world while plague-mock does not 00:55 < mmcgrath> | yep 00:55 < nirik> | yes, I think thats the cause 00:55 < f13> | ok. 00:55 < nirik> | case 00:55 < f13> | knurd: because koji manages it's own repos, it can't currently make use of $RANDOM_REPO_URL 00:55 * | stahnma was wondering that too 00:55 < f13> | mbonnet: perhaps this is another case for enabling koji to make use of an unmanaged repo? 00:55 < mmcgrath> | koji is plagues bigger brother who uses crack but it doesn't kill him :) 00:55 < Jeff_S> | lol 00:56 < mmcgrath> | its plague to the extreme. 00:56 < knurd> | f13, k, thx for the pointers 00:56 < Jeff_S> | it makes him stronger and somewhat more dangerous? 00:56 < mmcgrath> | mbonnet: how much work do you think this is? 00:56 < nirik> | I thought koji was a gang... always tagging everything. ;) 00:56 < mmcgrath> | I mean, is it harder then enabling a new yum repo in some config? 00:56 < mbonnet> | mmcgrath: yes, much 00:57 < mmcgrath> | I mean, koji manages its own repos right? so it generates a config to point to itself? 00:57 < mmcgrath> | why can't it generate a config to point elsewhere? 00:57 < f13> | mmcgrath: there are other issues involved 00:57 < mmcgrath> | ahh, k 00:57 < mbonnet> | Because it scans the buildroot and expects every package it finds to be a known, tracked package 00:57 * | mmcgrath honestly doesn't know so pardon. 00:57 < f13> | mmcgrath: like what repo has precidence, when does it get updates, will the rpeodata change out from under it during a build, etc... 00:57 * | lmacken catches up on backlog real quick 00:58 < mbonnet> | I think the better answer is to make koji able to read packages from multiple trees 00:58 < mbonnet> | so we can make the RHEL tree protected while the Fedora tree is world-accessible 00:58 < f13> | mbonnet: well, and repodata that just points to the real path rather than hardlinks. 00:58 < mmcgrath> | sorry guys, I hate to do this but we're almost out of time. 00:58 < knurd> | mmcgrath, yeah, seems so 00:58 < f13> | (which hey, makes createrepo even faster!) 00:59 < mmcgrath> | knurd: should we open the floor real quick and see if anyone has anything pressing before we close? 00:59 < lmacken> | nirik: bodhi would work with plague if we could get it filesystem access to the build results. 00:59 < knurd> | lmacken, would that be a lot of work? 00:59 < lmacken> | nirik: since bodhi is in PHX and plague is at Duke.. we would have to do some sort of hacker 00:59 < mmcgrath> | lmacken: ahh, I can help you with that. It won't be quick but it'd work. 00:59 < nirik> | lmacken: cool. I think dgilmore would be the one to talk to there. 00:59 < lmacken> | sshfs or something? 00:59 < lmacken> | mmcgrath: word 00:59 < mmcgrath> | or a ssh tunnel 00:59 < knurd> | lmacken, then we could use that way for now, and fix koji latar 00:59 < knurd> | later 00:59 < lmacken> | sounds good to me 00:59 < nirik> | coolness. ;) 00:59 < mbonnet> | what's the timeframe here? 01:00 < mbonnet> | It's possible this change could be made to koji in 1-2 weeks 01:00 < knurd> | 1-2 weeks would be fine 01:00 < mmcgrath> | +1 01:00 < knurd> | even three or (max) 4 01:00 < mbonnet> | 3 is very doable 01:00 < nirik> | lmacken: how long to plug bodhi into plague? 01:00 < lmacken> | nirik: 0 seconds. 01:01 < f13> | please though, lmacken, can bodhi for F7 take precidence over bodhi for EPEL? 01:01 < nirik> | cool... if we can do that easily now that would be great. 01:01 < f13> | I'd hate to pull rank but.... 01:01 < lmacken> | f13: most definitely 01:01 < nirik> | yeah, totally understood there... 01:01 < knurd> | f13, has a point... 01:01 < lmacken> | nirik: actually, a few more seconds.. i would need to have each Release know of it's build results directory.. 2 lines 01:01 * | knurd then votes for the "fix koji" way 01:02 < nirik> | short term == bodhi talks to plague as lmacken's time permits? then longer term == fix to use koji ? 01:02 < knurd> | mbonnet, could you look into the solution you poposed and give us a status update over the next few days? 01:02 < Jeff_S> | I'm glad to help out w/ koji if wanted/needed 01:02 < lmacken> | nirik: if mmcgrath can hook me up with a tunnel or whatever to get access to the plague build results, plugging it into bodhi is trivial 01:02 <-- | wwoods has quit ("reboot for kernel update") 01:03 < mbonnet> | knurd: sure 01:03 < knurd> | mmcgrath, can you help coordinate this? 01:03 < knurd> | you seems to know the details and the people involved 01:03 < mmcgrath> | as in drive it? 01:03 < nirik> | I'd be happy to help testing bodhi too... either f7 or epel. ;) 01:03 < knurd> | mmcgrath, yes, as in driving "bring the right people together" 01:03 < mmcgrath> | sure 01:03 < knurd> | mmcgrath, thx 01:03 < lmacken> | nirik: i should have something testable tonight or tomorrow 01:03 < knurd> | then let's move on 01:04 < mmcgrath> | its about that time 01:04 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 01:04 < knurd> | anything else? 01:04 * | knurd will close the meeting in 60 01:04 < knurd> | sorry, we are late 01:04 < knurd> | anything important? 01:04 < mmcgrath> | nothing here 01:04 * | knurd will close the meeting in 30 01:04 * | stahnma will try to be more active next time 01:05 * | knurd will close the meeting in 10 01:05 < knurd> | -- MARK -- Meeting end 01:05 --- | knurd has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting From dag at wieers.com Thu May 24 16:43:51 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 24 May 2007 18:43:51 +0200 (CEST) Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <4655B3C7.4070002@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> Message-ID: On Thu, 24 May 2007, Thorsten Leemhuis wrote: > 00:25 < mmcgrath> | Jeff_S: what if getting more people means talking > about one issue for months on end when 'more people' means 3 or 4 people? We're talking about incompatibility with future CentOS Extras, with users using RPMforge and ATrpms. (again see the clamav example) > 00:26 < mmcgrath> | rdieter: I'd argue that even if this consession > was made they wouldn't participate. We do not ask to evaluate repotags in order for us to join. repotags have advantages to users and make repositories work together. Without them dependency problems are problematic with current tools. repotags just shows if EPEL/Fedora cares about the existing RHEL/CentOS users/community. If EPEL/Fedora does not care about us, why should we care about EPEL ? > 00:28 < f13> | for EPEL to be successful as a place to get > packages and promoted by Red Hat like Fedora Extras was, the software > must be available in EPEL. Sure, and EPEL's packaging policy provides everything any user wants. Backports and most recent versions and experimental stuff. EPEL rules them all (even though EPEL is the new kid on the block). Existing users, you have been stupid to choose something when EPEL was not available, because now you'll have to fix up. > 00:28 < mmcgrath> | and not one person here is actually in favor of > repo tags. There's just people in favor of working with other people > who aren't part of our community who are in favor of repo tags. Ok, then I'd prefer you don't adopt it and we simply say CentOS Extras/ATrpms/RPMforge is NOT compatible with EPEL. Please don't use EPEL. > 00:29 < nirik> | after reading that rpmforge and atrpms have > already dropped the repotag, I think we shouldn't bother to try and add > it... We did not. You could have verified this. > 00:30 < f13> | and since RHEL itself doesn't have a repo tag, > this is all irrelevant. Bogus, enterprise users (and Red Hat support) would like to see when packages are not supported. A repotag is a means to an end. Sure there are other options, but none which work with current tools. > 00:31 < f13> | rdieter: explain to me how we can take advantage > of packages only being available in a non Fedora repo that we can't > mention due to legal reasons? > 00:31 < f13> | rdieter: how is that any good to us? Are we being egoistic here ? EPEL rules them all. Why should EPEL care ? Since when do users no longer count. > 00:32 < f13> | while at the same time including illegal stuff > thus tainting the entire repo > 00:32 < f13> | which is why we can't ship a repo file for them > in Fedora, why we can't mention them in our wiki, etc.. etc.. And why Red Hat will not ship with EPEL. But CentOS will ship with CentOS Extras (and not EPEL). > 00:34 < f13> | I'm just failing to see the value in "working > with" a set of repos that we can't mention, we can't guide users to, we > can't preconfigure user's systems for, we can't expect users to > magically discover that there is another repo they have to manually add > to get access to potentially useful software, that we could just put in > repos that we _can_ guide users to. How about users that already have RPMforge, ATrpms configured ? I guess they are excluded to use EPEL, right ? This is silly. First of all nobody mentions that without repotags the current infrastructure DOES NOT allow packages from different repositories to work reliably together. Not using repotags is dismissing the existence or collaboration with other packages. Secondly, someone brings up that both atrpms and rpmforge do not longer use a repotag, which is NOT true. We had the intention to drop it after Fedora/EPEL Refused to consider it. And now they use our intention (which is not yet policy) as a reason to refuse it. Sigh. Can someone hand me the cluestick ? It's nice that the meetings are done in an open fashion, it shows that the EPEL mentality is the same as the Fedora Extras mentality. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Thu May 24 17:09:02 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 24 May 2007 19:09:02 +0200 (CEST) Subject: repotags proposal In-Reply-To: References: <465051FB.3030604@leemhuis.info> <4653EEAE.5040304@rasmil.dk> Message-ID: On Thu, 24 May 2007, Panu Matilainen wrote: > On Wed, 23 May 2007, Dag Wieers wrote: > > On Wed, 23 May 2007, Tim Lauridsen wrote: > > > Panu Matilainen wrote: > > > > > > > My 5c on the topic I've been trying to avoid because it's too flammable > > > > for > > > > my taste. I hate politics so I'm not going to get into that, I'm > > > > commenting > > > > from purely technical POV, and actually have a proposal that might make > > > > them > > > > unnecessary. > > > > > > > > Repotags as part of release string are just plain wrong. Unlike disttag, > > > > the > > > > repotag does not have a meaningful version information in it, it's > > > > really > > > > just a fuzz-factor to somehow differentiate packages coming from > > > > different > > > > places. > > > > It does have meaningful version information in a multi-repository world. > > It shows what version of the package you have. rf means this is the > > RPMforge version. It makes the package/filename/version unique ! > > Actually you could make the package filename contain a repotag just by > tweaking %_build_name_fmt macro on the buildsystem. The packages themselves > have plenty of uniquely identifying data in them, strongest of which is the > signature (if present). It's just that the current tools dont allow using the > data to full extent. Yes, that would replace one of the things that repotags are useful for. But not the most important. They make the version/release unique. (cross-repository) > > Granted, the repotag does not have any real meaning in "version > > comparison" between packages from different repositories. Neither does the > > release tag. The release tag has no meaningful version information between > > packages from different repositories. > > Indeed (in the "is another package newer" sense) - like you noted it does have > a meaning in non-automatic, versioned (sub-)package dependencies. This has (now) become the most overlooked benefit of repotags :) > > > > The perfect repotag would actually be the package's gpg signature: > > > > - it's not involved in version comparison > > > > - it can't be faked by locally rebuilding a package - it's recorded in > > > > rpmdb > > > > so it's possible to see where a package came from > > > > It is not a perfect repotag for other reasons: > > - It doesn't make the filename unique (or gives insight of the package > > before downloading) > > - It is not shown when one has dependency problems, either on yum, apt or > > rpm level > > See above, filename "uniqueness" is easily solvable. Making a human-friendly > signature visible in the tools obviously requires some modifications to the > tools. So it might not help RHEL 2.1 or Fedora 7, but I'd rather try and start > fixing the problems so I don't have to read about repotag arguments five years > from now. Oh, I do not object in engineering future solutions. But that's not what we are discussing within EPEL or RPMforge. We create packages that are available for 7 years ! RHEL5 has just been released and we'll have packages going into 2014. We'll have to see if EPEL actively supports RHEL5 when RHEL7 is release, like RPMforge actively supports RHEL2.1 and RHEL3 now. As I mentioned to you before, Panu, is that my last contract was to migrate RHEL2.1 to RHEL3 ! Yes, in 2007 companies migrate to RHEL3. Reasons are vendor-support of tested applications. That's production. New systems are being deployed with RHEL4 now as well, but RHEL3 is what most of production is using. People that now start afresh with RHEL5 are just lucky chaps, living a bit on the edge :) > > > > For depsolvers, you need some sort of priorisation mechanism anyway to > > > > make > > > > any sense out of mixed repository situation. So the repotag mostly > > > > serves as > > > > a visual clue to humans. All the major depsolvers now have some means to > > > > priorize between repositories so what the actual rpm EVR string is > > > > doesn't > > > > really matter, what's missing is the visual clue. > > > > The major depsolvers lack a meaningful way for a user to provide a policy > > of what they want to do with repositories or packages. Some plugins do > > allow somewhat more, but there are many shortcomings and without repotags > > errors are at first sight inexplicable or confusing. > > > > Especially when packages from different repositories have the same NEVR, > > similar sub-packages and have dependencies between them. > > > > The clamav package is a nice example. Without repotags, dependencies would > > exists between packages from different repositories. > > Yup. See my other mail for an idea wrt this. Again, wont help you for existing > releases. > > But that's just part of the problem... manual, versioned dependencies are a > minority in the package dependency data, the vast majority is automatically > generated soname dependencies where there are no repotags and things can (and > do) get pretty mixed up easily. It might help if yum etc could try to first > resolve dependencies from the same repo where the dependency itself comes > from. True, it does not necessarily fix all problems. But the most obvious ones are the subpackages depending on each other and on the base package. > > Saying that repotags have no meaningful version information is very wrong. > > It makes the system work. > > "Prevents the system from totally blowing up" would be closer to reality I > think :) Right. It helps a bit, plus it adds the other benefits that others may not validate as a requirement. > > > > Long-term, more than that's needed to really solve the issues with > > > > repository mixing. One (perhaps crazy) idea is turning repotags into > > > > namespaces, and dependencies are first looked up within that namespace > > > > and > > > > only if unsolved, other namespaces are looked at in (configurable) > > > > order. > > > > > > > > An example (please excuse the :: notation, that's not a good choice but > > > > for > > > > examples sake...): assume we have packages foo and bar which both depend > > > > on > > > > glibc, and foo additionally depends on bar. Foo and bar are available > > > > from, > > > > say, both EPEL and ATrpms: > > > > > > > > rhel::libxml2-2.6.28-1 > > > > epel::foo-1.2-1 > > > > atrpms::foo-1.2-1 > > > > epel::bar-2.4-5 > > > > atrpms::bar-2.4-1 > > > > > > > > If you install atrpms::foo, as atrpms namespace also provides bar, that > > > > one > > > > gets selected instead of epel::bar even though it's evr is higher. The > > > > actual namespace could internally be the gpg signature, only mapped to a > > > > human readable where exposed to the user. Sound crazy enough? ;) > > > > > > Yes, i sounds very crazy to me ;-) ;-) . > > > I dont know if this can be done without a lot of changes into RPM. > > > > The namespace idea is an interesting one and when it gets implemented and > > is ready is surely an alternative to repotags. > > > > But it is not ready and will not be in EL2.1, EL3, EL4 or EL5. So we > > cannot consider it an alternative because we cannot use it now. > > > > It's not that I'm unwilling to see an alternative, it's just that there is > > NO alternative to repotags that cover it's different uses. > > > > > Nice to see something constructive to solve the real problems. > > > > It doesn't solve real problems as it is not a realistic solution yet. > > Yes, I don't have a solution, but repotags are not a solution either, just a > bandaid. I'd rather attempt to have a constructive discussion how to solve the > bleeping problems for good. But this isn't the best forum for that discussion, > going crazy with package/dependency namespaces and whatnot concerns far more > people than are involved in epel... At this point it's either bandaid or nothing. I'd prefer the bandaid, thos prefering nothing do not see the whole repository picture but look inside EPEL only. Existing RPMforge/ATrpms/CentOS users beware ! Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Fedora at FamilleCollet.com Thu May 24 17:27:35 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 24 May 2007 19:27:35 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: References: <4655B3C7.4070002@leemhuis.info> Message-ID: <4655CB07.1040601@FamilleCollet.com> Reading this : I'm totally disappointed I'm really sad. I work in a very large company which use RedHat EL AND Dag RPM on hundreds of servers for a very long time. I saw EPEL as a great opportunity for the EL community. I hoped Dag, and other third repo mainteners will work with US on this "great" project. This discussion seems to mean it couldn't be possible. I don't understand what happen (even reading a lot of thread). Once more : i'm really sad. Great regards to Dag, i think your work is really need by the EL users and i've learn a lot by reading you spec files. And today, i don't think my company will switch for the very long time used Dag's RPM to EPEL. I still hope we could find a good collaboration solution. Remi. From dag at wieers.com Thu May 24 17:37:01 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 24 May 2007 19:37:01 +0200 (CEST) Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <4655CB07.1040601@FamilleCollet.com> References: <4655B3C7.4070002@leemhuis.info> <4655CB07.1040601@FamilleCollet.com> Message-ID: On Thu, 24 May 2007, Remi Collet wrote: > I still hope we could find a good collaboration solution. CentOS Extras will likely be the CentOS alternative to EPEL and since Axel and me will join this initiative there will be an upgrade path to CentOS Extras. Of course, if you're running RHEL and not CentOS, there is no cause for worrying. CentOS and RHEL are binary compatible, so CentOS Extras works as well on RHEL as RPMforge or ATrpms did in the past. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Axel.Thimm at ATrpms.net Thu May 24 19:41:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 May 2007 21:41:29 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <4655B3C7.4070002@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> Message-ID: <20070524194129.GC7366@neu.nirvana> On Thu, May 24, 2007 at 05:48:23PM +0200, Thorsten Leemhuis wrote: > 00:06 < nirik> | I don't like them, but dag, thimm, planetccrm, > etc are all mad... if it will make them happy and we can do it some way > easily I would do it just to make them all happy. Repotags are dead. EPEL killed them, much to the distaste of all other kids on the block. It was painful and ugly and consumed a lot of my time to knock down something that did not replace slicing bread or cubed ice, but made a lot of sense for a healthy repo ecostructure. But it is not about repotags, not about whether they work perfectly, not at all, half-way, kludgy or as a temporary workaround until rpm is replaced by a next generation packager. It is about *all* repos coming to EPEL, kindly asking to not destroy the repotag system that was in place and EPEL ignoring it in return. Now "they are all mad"? If all repos would come to me and ask me to do something I would consider it and not arrogantly respond with "I see no technical benefit" (original SC tone) and "We aim higher than you" (also original SC). No, this has left the plain repotag issue quite some time ago. This is about EPEL (or some people inside EPEL) clearly showing the agenda: No coexistance with other repos (other than a "doesn't fit in EPEL" spinoff). > 00:17 < mmcgrath> | nirik: after all, none of those people are even > here right now. > 00:26 < mmcgrath> | none of whom care about epel enough to be here. Well, one by one they have been driven away, what do you expect? You can bang you heart against some mad bugger's wall only so many times. > 00:23 < mmcgrath> | nirik: that email seems to indicate to me that > this is a completely political issue. one that has done nothing but > distract us. Repotags were a political issue from the very beginning, the vote was even tagged as carrying 99% political content. In a single repo world repotags offer no added value, it's when there is more than a repo that it makes sense to use them. It's all about being nice to neighbors, e.g. politics. And it's about positive politics when repos agree to accept a cross-repo defacto standard. And it's bad politics when it shows that one repo is not interested in working with the others. You feel distracted? Just ask yourself who has been investing energy and time into this? You? No, the people that are distracted are the people that came to epel thinking that there would be some cooperation, that invested in epel, that tried to talk sense to people here, and now see that this was all in vain. > 00:24 * | mmcgrath notes thimm is used to running a repo where his > rule is law. Now how helpful is this comment and what does this have to do with the whole discussion? "thimm" has been bending his "rules" and "laws" to accomodate Fedora "rules" and "laws" since quite some time. Slapping me now in the face is both unfair and completely unnecessary. But these are the kind of actions that alienate repos even further. > 00:24 < f13> | Jeff_S: but if EPEL wants all software avialble to > users, all said software has to be in EPEL, which really obsolets > the other repos. This is a valid logic. But the same is true for all other repos as well. So projecting this to all repos, we would all be rightfully obsoleting each-other and walk down to repo Darwinism. It does look a lot like epel is taking that road. It's not like it isn't a promising road, that's how fedora.us started off as well. > 00:25 < rdieter> | f13: that's a bad attitude (EPEL obsoletes all), > best to be avoided (no matter how close to the truth it really is). No, don't avoid opening up any such agenda to the public. I was fooled into believing that epel was going to play nice. Now the cards are being layed on the table, and I know better. As well as all other repo maintainers. > 00:27 < mmcgrath> | hell, thimm was the closest person and he does > not have a single epel package. Hell, and mmcgrath manages the repo and does not even check what he's saying, before he spreads false statements. All my packages were imported and built for epel months ago (accidentially even the ones that made no sense to build for epel like fedora-package-config-*). I even had an epel bugzilla entry for an already shipped package. When I stepped down I asked dgilmore to orphan or remove them now that I cannot commit anymore to EPEL. They are still in the repo though, so I really wonder what makes you thing that I have (or had) "no single epel package"? You should really check your facts before making public statements. > 00:29 < f13> | it's the same reason why Fedora Extras really > obsoleted other repos aside from the illegal stuff. Please be careful with pissing off people even across the epel border. The "other repos" are far from obsolete and far from being illegal. > 00:39 < mmcgrath> | I know my approach isn't very diplomatic but > this has gotten silly. Not being diplomatic is probably the core flaw in epel's steering committee. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu May 24 20:06:44 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 May 2007 15:06:44 -0500 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <20070524194129.GC7366@neu.nirvana> References: <4655B3C7.4070002@leemhuis.info> <20070524194129.GC7366@neu.nirvana> Message-ID: <4655F054.2030506@redhat.com> Axel Thimm wrote: The more appropriate time to make these comments is at the meetings. I don't like that you've made me look like a bad guy in your comments. I'm sorry things didn't go as you expected them to. -Mike From Axel.Thimm at ATrpms.net Thu May 24 20:20:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 May 2007 22:20:17 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <4655F054.2030506@redhat.com> References: <4655B3C7.4070002@leemhuis.info> <20070524194129.GC7366@neu.nirvana> <4655F054.2030506@redhat.com> Message-ID: <20070524202017.GF7366@neu.nirvana> On Thu, May 24, 2007 at 03:06:44PM -0500, Mike McGrath wrote: > Axel Thimm wrote: > > The more appropriate time to make these comments is at the meetings. I > don't like that you've made me look like a bad guy in your comments. I'm not making you look like a bad guy, I just quoted what you were saying in the meeting. And I won't be attending meetings just to police what is being said. > I'm sorry things didn't go as you expected them to. Yes, me too, and it looks like many people feel that way. But anyway that's life. We should wrap up and move on. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu May 24 20:27:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 22:27:38 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <4655B3C7.4070002@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> Message-ID: <20070524202738.GF12227@free.fr> On Thu, May 24, 2007 at 05:48:23PM +0200, Thorsten Leemhuis wrote: > 00:00 --- | knurd has changed the topic to: EPEL Sig meeting I won't quote, since it is more a general impression than something that was clearly said, but it looks like to me that EPEL is taking the route of the 'world repo domination'. There is some limited will to work with other repos, but only to attract their developpers. If it is so, this should be communicated clearly and it is completely ridiculous to say something in http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration and something else in the meetings. Nobody voiced against that document although it looks like it doesn't reflect the state of EPEL. To be clear, I don't really mind about cooperation or world domination, as I said elsewhere boths models have advantages and inconvenients but we have to be clear to avoid expectation being deceived. -- Pat From pertusus at free.fr Thu May 24 21:16:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 23:16:11 +0200 Subject: some issues regarding infos on RHEL packages Message-ID: <20070524211611.GB16125@free.fr> Hello, I am checking which package I'd like to put in EPEL and it appears that some informations are lacking, that I can find easily with rpmfind, but I cannot for RHEL. Here is a list of things I would like to do, from a non Centos/RHEL box, or from another Centos/RHEL version, of course. Do you have guidance on how to do it? Keep in mind that I want something easy, like what rpmfind provides, not something unworkable: * find whether a package is in RHEL or not * find whether a file is in RHEL or not, and in which package * find whether a provides is in RHEL or not, and provided by which package * find the list of files and provides of a package in RHEL Any idea on how to achieve that? -- Pat From mastahnke at gmail.com Fri May 25 00:52:38 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 24 May 2007 19:52:38 -0500 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <20070524202738.GF12227@free.fr> References: <4655B3C7.4070002@leemhuis.info> <20070524202738.GF12227@free.fr> Message-ID: <7874d9dd0705241752g2d8051f4ye0ecc1efea96442d@mail.gmail.com> On 5/24/07, Patrice Dumas wrote: > On Thu, May 24, 2007 at 05:48:23PM +0200, Thorsten Leemhuis wrote: > > 00:00 --- | knurd has changed the topic to: EPEL Sig meeting > > I won't quote, since it is more a general impression than something that > was clearly said, but it looks like to me that EPEL is taking the route > of the 'world repo domination'. There is some limited will to work with > other repos, but only to attract their developpers. > > If it is so, this should be communicated clearly and it is completely > ridiculous to say something in > http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration > and something else in the meetings. Nobody voiced against that document > although it looks like it doesn't reflect the state of EPEL. It should be noted that these points of contention are not viewed the same among all members of the steering committee, and certainly not all members of EPEL. The writers of that RepositoryCollaboration statement were not all that involved in this discussion. The lack of cooperation made me uncomfortable yesterday, and continues to make me uneasy today. I moved to open source to work with the best minds in the industry, worldwide. I know not everyone is going to get along all the time, but if we can identify high-level goals and work toward them, everyone should and would benefit. Sadly, we are caught in an endless debate that morphs into flaming and hard-feelings. I don't have an answer right now to the problem (and the problem is well beyond repotags), but I do hope one emerges in the near future. Currently the userbase is the most affected by this lack of cooperation, and they should be the most important. stahnma From ivazqueznet at gmail.com Fri May 25 04:17:06 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 25 May 2007 00:17:06 -0400 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <20070524202017.GF7366@neu.nirvana> References: <4655B3C7.4070002@leemhuis.info> <20070524194129.GC7366@neu.nirvana> <4655F054.2030506@redhat.com> <20070524202017.GF7366@neu.nirvana> Message-ID: <1180066626.6594.10.camel@ignacio.lan> On Thu, 2007-05-24 at 22:20 +0200, Axel Thimm wrote: > And I won't be attending meetings just to > police what is being said. Of course not. You (and Karan, and Dag, and Dries, and Matthias, and everyone else that has a EL repo) should be attending because you have a stake in the outcome. Yes, it's going to be as unpleasant as standing in a pit of vipers for everyone involved, but do it in good faith regardless. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Fri May 25 06:21:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 May 2007 08:21:06 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <7874d9dd0705241752g2d8051f4ye0ecc1efea96442d@mail.gmail.com> References: <4655B3C7.4070002@leemhuis.info> <20070524202738.GF12227@free.fr> <7874d9dd0705241752g2d8051f4ye0ecc1efea96442d@mail.gmail.com> Message-ID: <20070525062106.GB2842@free.fr> On Thu, May 24, 2007 at 07:52:38PM -0500, Michael Stahnke wrote: > > It should be noted that these points of contention are not viewed the > same among all members of the steering committee, and certainly not > all members of EPEL. Indeed, but the whole impression I get is that in the steering commitee there are people frankly in favor of 'all free software packages in EPEL' while others don't seem to care. As shown in the fedora case what the members of EPEL that are in the minority think is not of much relevance. Nobody will stop them to do what they want at their level (including doing things contradictory with what comes from the steering commitee), but their advice will only have a consequence of lengthy threads. > The writers of that RepositoryCollaboration > statement were not all that involved in this discussion. At some point being there to argue a political point when in a minority is not worth the effort. Sometimes even for technical point it is worthless and time consuming. Even if the people weren't there, their arguments and positions were in everybody mind, so it doesn't make a difference in my opinion. It could have delayed the meeting and add some impolite statements in it, but I don't think it would have been different. > them, everyone should and would benefit. Sadly, we are caught in an > endless debate that morphs into flaming and hard-feelings. I disagree. Those endless debates are there because there are different models of development and every choice makes somebody unhappy. A choice of one repo with all the packages against a variety of repo is going to make somebody unhappy whatever is choosen. > I don't have an answer right now to the problem (and the problem is > well beyond repotags), but I do hope one emerges in the near future. There is no problem as such, but a choice to be made. The Fedora example shows that it is possible to almost replace the other repos, and as somebody pointed out the Fedora model has some advantages over the multi-repo situation. This is clearly an uncollaborative solution but it may be the best one -- or not. > Currently the userbase is the most affected by this lack of > cooperation, and they should be the most important. No, they shouldn't. The choice ebetween one big repo or a multi-repo world has to be done within EPEL. Whatever the choice is it may fail, for example the one big repo could be choosen but history may be different from what happened to fedora. In any case users are not involved a lot in this issue except that they are the long-term target. In any case the choice should be done, because it should impact the development path of EPEL. For example if the one big repo solution is used there should certainly be a specific repo with the latest versions, not only the default EPEL repo, the repotag issue is moot. If the multi-repo alternative is chosen, then there is a need to work with other repos, for example to have them split out non-free or illegal in the US part such that their repos may be in the default config, new processes and infrastructures are needed to play nice in a multi-repos world with some agreement on some standardizations. -- Pat From Axel.Thimm at ATrpms.net Fri May 25 06:53:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 25 May 2007 08:53:19 +0200 Subject: Log from yesterdays (20070523) EPEL SIG meeting In-Reply-To: <1180066626.6594.10.camel@ignacio.lan> References: <4655B3C7.4070002@leemhuis.info> <20070524194129.GC7366@neu.nirvana> <4655F054.2030506@redhat.com> <20070524202017.GF7366@neu.nirvana> <1180066626.6594.10.camel@ignacio.lan> Message-ID: <20070525065319.GI7366@neu.nirvana> On Fri, May 25, 2007 at 12:17:06AM -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2007-05-24 at 22:20 +0200, Axel Thimm wrote: > > And I won't be attending meetings just to police what is being > > said. > > Of course not. You (and Karan, and Dag, and Dries, and Matthias, and > everyone else that has a EL repo) should be attending because you have a > stake in the outcome. Yes, it's going to be as unpleasant as standing in > a pit of vipers for everyone involved, but do it in good faith > regardless. Well, in case you missed it I *was* attending the meetings and I was even in the steering committee until things had me step down, because epel took such a bad course, and there is just so much man-material in me that can burn out. I was involved in most viper-filled mail threads as well, so I was surely not avoiding the pain. If I can't make a difference as a voting member, why should I be more successful as a random observer? In the worst case people would accuse me of distracting the discussion. My former seat is the one labeled vacant and you should volunteer to get on it and see if you can try to do something. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri May 25 16:59:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 25 May 2007 12:59:53 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-25 Message-ID: <20070525165953.B0941152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 16 NEW arp-scan-1.6-1.el5 : Scanning and fingerprinting tool bcfg2-0.9.3-2.el5 NEW gammu-1.10.0-2.el5 : Command Line utility to work with mobile phones NEW graphviz-2.12-8.el5 : Graph Visualization Tools NEW halberd-0.2.1-1.el5 : Tool to discover HTTP load balancers NEW jasper-1.900.1-2.el5 : Implementation of the JPEG-2000 standard, Part 1 NEW ncarg-4.4.1-9.el5 : A Fortran and C based software package for scientific visualization NEW netcdf-3.6.1-4.el5 : Libraries for the Unidata network Common Data Form (NetCDF v3) (!) perl-IO-Multiplex-1.08-5.el5 : INVALID rebuild, not published! perl-libwhisker2-2.4-3.el5 NEW perl-Math-Base85-0.2-2.el5 : Perl extension for base 85 numbers, as referenced by RFC 1924 NEW perl-Net-Pcap-0.14-2.el5 : Interface to pcap(3) LBL packet capture library NEW perl-Nmap-Parser-1.05-3.el5 : Parse nmap scan data with perl NEW perl-Proc-Daemon-0.03-1.el5 : Run Perl program as a daemon process NEW plone-2.5.3-1.el5 : User friendly and powerful open source Content Management System NEW zope-2.9.7-2.el5 : Web application server for flexible content management applications Packages built and released for Fedora EPEL 4: 16 bcfg2-0.9.3-2.el4 NEW drgeo-1.1.0-6.el4 : Interactive educational geometry software freehdl-0.0.4-2.el4 NEW halberd-0.2.1-1.el4 : Tool to discover HTTP load balancers hdf-4.2r1-8.el4.1 ircd-hybrid-7.2.3-1.el4 jasper-1.900.1-2.el4 libupnp-1.4.6-1.el4 NEW ncarg-4.4.1-9.el4 : A Fortran and C based software package for scientific visualization NEW netcdf-3.6.1-1.el4 : Libraries for the Unidata network Common Data Form (NetCDF v3) perl-libwhisker2-2.4-3.el4 NEW perl-Math-Base85-0.2-2.el4 : Perl extension for base 85 numbers, as referenced by RFC 1924 NEW perl-Nmap-Parser-1.05-3.el4 : Parse nmap scan data with perl NEW perl-Proc-Daemon-0.03-1.el4.1 : Run Perl program as a daemon process qucs-0.0.11-1.el4 NEW ushare-0.9.10-1.el4 : UPnP (TM) A/V Media Server Changes in Fedora EPEL 5: arp-scan-1.6-1.el5 ------------------ * Sun May 06 2007 Sindre Pedersen Bj?rdal - 1.6-1 - Initial build bcfg2-0.9.3-2.el5 ----------------- * Tue May 22 2007 Jeffrey C. Ollie - 0.9.3-2 - Drop requires on pyOpenSSL - Add requires on redhat-lsb - (Fixes #240871) gammu-1.10.0-2.el5 ------------------ * Mon May 21 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.10.0-2 - Rebuild for CVS import. * Tue May 08 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.10.0-1 - Initial RPM release. graphviz-2.12-8.el5 ------------------- * Thu May 24 2007 Patrick "Jima" Laughton 2.12-8 - Pulled spec from devel/ - Adapted spec to build for EL-5 (thanks to Christopher Stone) * Sat May 05 2007 Patrick "Jima" Laughton 2.12-7 - Patch to fix BZ#237496 - Disabling relocatability to work around BZ#237082 - Disabling -ocaml and -sharp subpackages for ppc64 to remedy BZ#239078 halberd-0.2.1-1.el5 ------------------- * Thu May 03 2007 Sindre Pedersen Bj?rdal - 0.2.1-1 - Initial build jasper-1.900.1-2.el5 -------------------- * Wed May 23 2007 Rex Dieter 1.900.1-2 - CVE-2007-2721 (#240397) ncarg-4.4.1-9.el5 ----------------- * Mon Feb 12 2007 - Orion Poplawski - 4.4.1-9 - Fix up the source files that were modified then checked in :-(. netcdf-3.6.1-4.el5 ------------------ * Sat Sep 02 2006 Ed Hill - 3.6.1-4 - switch to compat-gcc-34-g77 instead of compat-gcc-32-g77 perl-IO-Multiplex-1.08-5.el5 ---------------------------- * Fri Sep 15 2006 Leif O M Bergman - 1.08-5 - Add dist tag perl-libwhisker2-2.4-3.el5 -------------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 2.4-3 - Fix patch to really include lw1 bridge perl-Math-Base85-0.2-2.el5 -------------------------- * Tue May 22 2007 Sindre Pedersen Bj?rdal - 0.2-2 - Add rfc1924.txt to %doc - Remove unnecessary BR - Fix license tag * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.2-1 - Initial build perl-Net-Pcap-0.14-2.el5 ------------------------ * Tue May 08 2007 Sindre Pedersen Bj?rdal - 0.14-2 - Add missing BR - Chance License to GPL or Artistic - Update %files - Include t/ in %doc * Thu May 03 2007 Sindre Pedersen Bj?rdal - 0.14-1 - Initial build perl-Nmap-Parser-1.05-3.el5 --------------------------- * Fri May 09 2008 Sindre Pedersen Bj?rdal - 1.05-3 - Move end-of-line fix to %prep - Update dos2unix BR * Tue May 08 2007 Sindre Pedersen Bj?rdal - 1.05-2 - Don't package Manifest - Fix permissions - Fix end-of-line encoding - Add missing BRs * Wed May 02 2007 Sindre Pedersen Bj?rdal - 1.05-1 - Initial build perl-Proc-Daemon-0.03-1.el5 --------------------------- * Sat Feb 11 2006 Remi Collet 0.03-1 - initial spec for Extras plone-2.5.3-1.el5 ----------------- * Wed May 23 2007 Jonathan Steffan 2.5.3-1 - Fixed CacheFu squid scripts (removed pyc and pyo) - Updated to 2.5.3 zope-2.9.7-2.el5 ---------------- * Wed May 23 2007 Jonathan Steffan 2.9.7-2 - Added zope.pth to fix misc. zope scripts including some zeo stuff Changes in Fedora EPEL 4: bcfg2-0.9.3-2.el4 ----------------- * Tue May 22 2007 Jeffrey C. Ollie - 0.9.3-2 - Drop requires on pyOpenSSL - Add requires on redhat-lsb - (Fixes #240871) drgeo-1.1.0-6.el4 ----------------- * Sun May 20 2007 Eric Tanguy - 1.1.0-6 - Remove BR perl-XML-Parser, gtk2-devel, libxml2-devel - Add BR intltool, gettext * Thu May 17 2007 Eric Tanguy - 1.1.0-5 - Add BR perl-XML-Parser freehdl-0.0.4-2.el4 ------------------- * Thu Apr 19 2007 Eric Tanguy 0.0.4-2 - Add texinfo to BuildRequires * Sat Apr 07 2007 Eric Tanguy 0.0.4-1 - Update to 0.0.4 - Patch for no info dir entry in `/usr/share/info/fire.info.gz halberd-0.2.1-1.el4 ------------------- * Thu May 03 2007 Sindre Pedersen Bj?rdal - 0.2.1-1 - Initial build hdf-4.2r1-8.el4.1 ----------------- * Thu May 24 2007 Orion Poplawski 4.2r1-8.1 - Remove netcdf-devel requires. (bug #239631) ircd-hybrid-7.2.3-1.el4 ----------------------- * Mon Aug 28 2006 Eric Tanguy - 7.2.3-1 - Update de 7.2.3 * Mon Aug 28 2006 Eric Tanguy - 7.2.2-3 - Rebuild for Fedora Extras 6 * Mon Aug 28 2006 Eric Tanguy - 7.2.2-2 - Rebuild for Fedora Extras 6 jasper-1.900.1-2.el4 -------------------- * Wed May 23 2007 Rex Dieter 1.900.1-2 - CVE-2007-2721 (#240397) libupnp-1.4.6-1.el4 ------------------- * Tue May 01 2007 Eric Tanguy - 1.4.6-1 - Update to version 1.4.6 * Sat Apr 21 2007 Eric Tanguy - 1.4.4-1 - Update to version 1.4.4 * Tue Mar 06 2007 Eric Tanguy - 1.4.3-1 - Update to version 1.4.3 * Fri Feb 02 2007 Eric Tanguy - 1.4.2-1 - Update to version 1.4.2 ncarg-4.4.1-9.el4 ----------------- * Mon Feb 12 2007 - Orion Poplawski - 4.4.1-9 - Fix up the source files that were modified then checked in :-(. netcdf-3.6.1-1.el4 ------------------ * Thu May 24 2007 Orion Poplawski - 3.6.1-1 - Update to 3.6.1 - Add FFLAGS="-fPIC" perl-libwhisker2-2.4-3.el4 -------------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 2.4-3 - Fix patch to really include lw1 bridge perl-Math-Base85-0.2-2.el4 -------------------------- * Tue May 22 2007 Sindre Pedersen Bj?rdal - 0.2-2 - Add rfc1924.txt to %doc - Remove unnecessary BR - Fix license tag * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.2-1 - Initial build perl-Nmap-Parser-1.05-3.el4 --------------------------- * Fri May 09 2008 Sindre Pedersen Bj?rdal - 1.05-3 - Move end-of-line fix to %prep - Update dos2unix BR * Tue May 08 2007 Sindre Pedersen Bj?rdal - 1.05-2 - Don't package Manifest - Fix permissions - Fix end-of-line encoding - Add missing BRs * Wed May 02 2007 Sindre Pedersen Bj?rdal - 1.05-1 - Initial build perl-Proc-Daemon-0.03-1.el4.1 ----------------------------- * Sat Feb 11 2006 Remi Collet 0.03-1 - initial spec for Extras qucs-0.0.11-1.el4 ----------------- * Sun Mar 18 2007 Eric Tanguy - 0.0.11-1 - Update to 0.0.11 ushare-0.9.10-1.el4 ------------------- * Mon Feb 26 2007 Eric Tanguy - 0.9.10-1 - Update to 0.9.10 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Sat May 26 09:36:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 26 May 2007 11:36:23 +0200 Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: References: <4655B3C7.4070002@leemhuis.info> Message-ID: <4657FF97.4030902@leemhuis.info> Hi all! On 24.05.2007 18:43, Dag Wieers wrote: > On Thu, 24 May 2007, Thorsten Leemhuis wrote: > [...] > Secondly, someone brings up that both atrpms and rpmforge do not longer > use a repotag, which is NOT true. We had the intention to drop it after > Fedora/EPEL Refused to consider it. And now they use our intention (which > is not yet policy) as a reason to refuse it. > > Sigh. Can someone hand me the cluestick ? I'm willing to, because I'm quite unhappy with that meeting and some of the statements that were made by EPEL Contributors and other Fedora contributors -- I was not present during that phase of the meeting (Sorry, real life); so in other words: >> 00:39 < mmcgrath> | If I removed this item from the schedule right >> now... who would bring it up next week? [...] >> 00:40 < nirik> | knurd: would you re-add it? Yes, I would and sooner or later. But I'm unsure if we should have a IRC meeting next weeks because afaics mmcgrath and I are on LinuxTag and likely not near a keyboard (see also below). Further: I'm actually so unhappy with the current situation that I'm willing to invest even more work to get repotags in EPEL4 and EPEL5 and will leave EPEL if we don't get them. I'd even go a step further and say now that I'll leave EPEL if we don't find a peaceful way of co-existence with Dag and Axel and CentOS. Maybe we can even get back to the drawing boards and find a way to cooperate. > It's nice that the meetings are done in an open fashion, it shows that the > EPEL mentality is the same as the Fedora Extras mentality. Please do not confuse opinions expressed by individuals with a general "EPEL mentality". Sure, those people are part of EPEL, but in big groups there are alway lot's of different opinions. So, as I said, I'm quite unhappy with the current EPEL state -- just as Dag, Axel and some others are. I'd really like to find a way out of this mess. Dag (you are on LinuxTAG afaik) and Axel (are you there or could we meet? maybe in the evenings if that's easier for you), can we please meet one or two hours on LinuxTag (Wednesday preferred) and find a way out of this mess that afaics to a big part evolved because mail communication sucks. A real life meeting maybe could get this mess solved. I'd actually would like to have someone around that could speak for CentOS, too. But not much more people as stuff might get confusing and unfruitful otherwise. Dag, Axel, what do you think? CU thl From lance at centos.org Sat May 26 09:42:26 2007 From: lance at centos.org (Lance Davis) Date: Sat, 26 May 2007 10:42:26 +0100 (BST) Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: <4657FF97.4030902@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> Message-ID: On Sat, 26 May 2007, Thorsten Leemhuis wrote: > Hi all! > > On 24.05.2007 18:43, Dag Wieers wrote: >> On Thu, 24 May 2007, Thorsten Leemhuis wrote: >> [...] >> Secondly, someone brings up that both atrpms and rpmforge do not longer >> use a repotag, which is NOT true. We had the intention to drop it after >> Fedora/EPEL Refused to consider it. And now they use our intention (which >> is not yet policy) as a reason to refuse it. >> >> Sigh. Can someone hand me the cluestick ? > > I'm willing to, because I'm quite unhappy with that meeting and some of > the statements that were made by EPEL Contributors and other Fedora > contributors -- I was not present during that phase of the meeting > (Sorry, real life); so in other words: > >>> 00:39 < mmcgrath> | If I removed this item from the schedule right >>> now... who would bring it up next week? > [...] >>> 00:40 < nirik> | knurd: would you re-add it? > > Yes, I would and sooner or later. But I'm unsure if we should have a IRC > meeting next weeks because afaics mmcgrath and I are on LinuxTag and > likely not near a keyboard (see also below). > > Further: I'm actually so unhappy with the current situation that I'm > willing to invest even more work to get repotags in EPEL4 and EPEL5 and > will leave EPEL if we don't get them. I'd even go a step further and say > now that I'll leave EPEL if we don't find a peaceful way of co-existence > with Dag and Axel and CentOS. Maybe we can even get back to the drawing > boards and find a way to cooperate. > >> It's nice that the meetings are done in an open fashion, it shows that the >> EPEL mentality is the same as the Fedora Extras mentality. > > Please do not confuse opinions expressed by individuals with a general > "EPEL mentality". Sure, those people are part of EPEL, but in big groups > there are alway lot's of different opinions. > > So, as I said, I'm quite unhappy with the current EPEL state -- just as > Dag, Axel and some others are. > > I'd really like to find a way out of this mess. Dag (you are on LinuxTAG > afaik) and Axel (are you there or could we meet? maybe in the evenings > if that's easier for you), can we please meet one or two hours on > LinuxTag (Wednesday preferred) and find a way out of this mess that > afaics to a big part evolved because mail communication sucks. A real > life meeting maybe could get this mess solved. I'd actually would like > to have someone around that could speak for CentOS, too. But not much > more people as stuff might get confusing and unfruitful otherwise. I will be at linuxtag :) Regards Lance > > Dag, Axel, what do you think? > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > uklinux.net - The ISP of choice for the discerning Linux user. From mmcgrath at redhat.com Sat May 26 15:01:42 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 26 May 2007 10:01:42 -0500 Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: <4657FF97.4030902@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> Message-ID: <46584BD6.1030503@redhat.com> Thorsten Leemhuis wrote: > Hi all! > > On 24.05.2007 18:43, Dag Wieers wrote: > >> On Thu, 24 May 2007, Thorsten Leemhuis wrote: >> [...] >> Secondly, someone brings up that both atrpms and rpmforge do not longer >> use a repotag, which is NOT true. We had the intention to drop it after >> Fedora/EPEL Refused to consider it. And now they use our intention (which >> is not yet policy) as a reason to refuse it. >> >> Sigh. Can someone hand me the cluestick ? >> > > I'm willing to, because I'm quite unhappy with that meeting and some of > the statements that were made by EPEL Contributors and other Fedora > contributors -- I was not present during that phase of the meeting > (Sorry, real life); so in other words: > > >>> 00:39 < mmcgrath> | If I removed this item from the schedule right >>> now... who would bring it up next week? >>> > [...] > >>> 00:40 < nirik> | knurd: would you re-add it? >>> > > Yes, I would and sooner or later. But I'm unsure if we should have a IRC > meeting next weeks because afaics mmcgrath and I are on LinuxTag and > likely not near a keyboard (see also below). > I'd like to clarify this because it needs clarification. To me, repotags are just repotags. I'm mildly against repo tags because we, as a fedora universe, don't use them. But to some, this is more about repo tags. I think to thimm, knurd and others its a political thing. So why have I been so vocal? We've voted twice and I want us to move on. Repotags are such a tiny tiny detail of what needs to be done. If you guys are interested in bringing up repo tags again, so we can vote a 3rd time, that's fine. But if its not repo tags, if it's something else political can we please define it that way? I can't possibly imagine the people involved in this have actually been concerned for two months about repo tags, especially since extras existed in the same space as these repos without repo tags and they all existed that way for YEARS. Why now? We can't talk about political issues in a technical way and we can't talk about technical issues in a political way. At least I can't. -Mike From herrold at owlriver.com Sat May 26 18:06:45 2007 From: herrold at owlriver.com (R P Herrold) Date: Sat, 26 May 2007 14:06:45 -0400 (EDT) Subject: dag, axel some from from centos, let's please meet on LinuxTag In-Reply-To: <4657FF97.4030902@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> Message-ID: On Sat, 26 May 2007, Thorsten Leemhuis wrote: > will leave EPEL if we don't get them. I'd even go a step > further and say now that I'll leave EPEL if we don't find a > peaceful way of co-existence with Dag and Axel and CentOS. > Maybe we can even get back to the drawing boards and find a > way to cooperate. Please don't threaten so, and please don't leave. -- As I see it, you have finally stopped fighting with Dag and Axel, and are more clearly thinking about the real world support implications of some so-called 'political' infighting within EPEL and Fedora. I appreciate your work. There is lots of history and and plenty of choices in all of our pasts -- some packagers have chosen to assent to the RHEL License, others have not or cannot; some have chosen to consent to the Fedora CLA, others have not, or cannot. Some have availablity, and spare time to 'pounce on email' to conduct 'conversations' in near real time, others do not. Some use IRC, some do not. I suspect that an amicable 'federation' is about all that one can achieve; in light of the Epoch wars, the repotags battles, and the EPEL tone to date, things are not promising, and at the end of the day, in FOSS, one can choose to fork. Not all differences among branches of a fork can be merged. My antecedents are readily knowable: I have been an independent packager since before there was a fedora.us; I co-founded cAos, and when the CentOS sub-project needed to seperate to address a certain trade mark threat and so forth, I was there. I publish GPLd code, and when GPL v 3 issues, we (my coding partner and I) have already concluded we will re-license and advertise our support for it at once. Spot and I have been in the versioning wars a long time; I strongly disagree with his current conclusions on repotags; some strongly disagreed with Red Hat on gcc-2.96 - - I find this in my archive from spot dated 06 Feb 2003; I heartily agreed with RH then, and in his build in Aurora and sparc space. > Because it isn't Perl 5.6.1sparc, its Perl 5.6.1. You're > opening a big old can of worms when you start modifing > someone else's release number (*cough*2.96RH*cough*). I _think_ he meant Version as there was no intervening dash. The fight moves from Version to Release, for repotag to live at at the RHS of, (some time ago I discussed the matter in private IRC directly with him, and we simply disagree) and as a matter to appear in the 'as built' external binary RPM name, or even in a NEVR to disambiguate, I _like_ repotags. But I cannot sign the CLA, and so cannot vote on the matter. Yes, I know, and concur that rpm -qi can do so, and so can signing keys (congratualtions, Panu on your new position) and more -- but in doing real world support, NEVR is about all one gets, as I see and do it. >From the May 23 IRC transcript meeting -- I have done minor snips from the IRC log, trying to get a thread which fairly presents what I see in reading the transcript which crossed this list. I _like_ spot [he has a standing dinner invitation whenever he is in my city], and I am a Red Hat shareholder, and I strongly respect the FSF Four Freedoms. These three cannot be reconciled to profit AND freedom maximize -- I live with the ambiguity. 00:34 < f13> | I'm just failing to see the value in "working with" a set of repos that we can't mention, we can't guide users to, we can't preconfigure user's systems for, we can't expect users to magically discover that there is another repo they have to manually add to get access to potentially useful software, that we could just put in repos that we _can_ guide users to. 00:35 < f13> | unless "working with" involves helping htem get all software that _can_ be published through EPEL into EPEL. later 00:50 < f13> | as that would essentially be giving away RHEL binaries for free and silly RHEL management doens't like that idea one bit. 00:51 * | mmcgrath notes we should have just used the centos binaries... 00:51 < f13> | nor do they like the alternative of using CentOS binaries. later 00:51 < mmcgrath> | f13: Do 'they' like epel at all? 00:51 < mmcgrath> | :) 00:51 < f13> | mmcgrath: oh sure! they LOVE epel.... 00:52 < mbonnet> | mmcgrath: "They" are all for EPEL 00:52 < f13> | (it gives them a place to say "no, we don't want to accept this new package in RHEL, go play in EPEL" later 00:53 < smooge> | well your build options look to be : RHEL but locked down and hidden, CentOS but not admitting it, or SciLinux but not admitting it 00:54 < stahnma> | OH, there's unbreakable linux too I think the main problem which EPEL has not faced, is that RHEL management (and control decisions in Fedora with the demise of the independent Fedora Community Foundation commitment ["one cannot serve two masters"]) are reportable to Red Hat management ("RHT"), and at the end of the day, I expect (wearing my shareholder's hat) RHT (its stock ticker symbol) to properly manage its assets, its brands, and its property to maximize shareholder value. The success in recruiting legions of Fedora folk says they are doing well; that I personally choose not to accept the License offered does not diminish my respect for their management of RHEL and Fedora. EPEL is another (non-Fedora) part of RHT's 'One Ring to Rule Them All', to my way of thinking -- A buildsystem building with restricted availability binaries, and a CLA are not for me, but may be for others. Until its buildsystem can be reconstructed using binaries from freely rebuildable sources, and until some FUD ceases, EPEL is not for me. I veered away (forked, if one prefers) a long time ago, to the initial fedora.us, then cAos, and am perfectly happy with it and CentOS. I still file bugs on the Red Hat Bugzilla as no CLA applies. I filed one earlier today, pro Freedom. Get over it, and move on. Diversity in packaging and buildsystems implementations may save us rather than cripple us. > So, as I said, I'm quite unhappy with the current EPEL state > -- just as Dag, Axel and some others are. I choose not to be unhappy as I consider it a fool's errand to seek some 'Grand Unification', and do not make myself unhappy wishing for things which cannot occur. For me, CentOS and my SRPM archive (for missing elements which customers have been provided) yields access to stability consistent with my views on the Four Freedoms -- I do not see that adding a EPEL binary archive can ever reduce risk in a production environment at my clients; cAos adds the latest and greatest for me if I wish to walk on the wild side -- Fedora has a CLA entry barrier. > I'd really like to find a way out of this mess. I wish you luck, but ... > afaics to a big part evolved because mail communication sucks. No -- email as practiced without proper trimming, and with snap responses without thought, rather than considered comment and responses sucks. IRC is even trickier, and I still get it wrong from time to time in #centos on freenode and the adjunct channels through the day. Come lurk for a week, and get the flavor of the participants. When Max showed up one day in #centos, I recognized him, and took him off for a nice pre-FOSDEM IRC meeting with the important CentOS developers who happened to be around [we are still waiting for some replies on matters discussed]; This is nothing new as I know most of the players from years in RPM, F, and RHEL space and can 'greet them' at the door. dgilmore was at ClueCon at my invitation last year as I presented on CentOS, CACert and telephony matters. Earlier in the year, I sought out and spoke with warren at SCALE. In between, I met up with seth in real life at OLS. One can only do so many conventions. ;) CentOS folks are not hard to find. Others from @redhat, and in Fedoraspace lurk there as well, and I suspect it is because of the S/N quality of the channel. CentOS folk are not hard to find, but is likely that out of courtesy to others there, discussions may move to a side channel. > A real life meeting maybe could get this mess solved. I'd > actually would like to have someone around that could speak > for CentOS, too. I believe Lance has stated his intention to be at the event, and Lance is thoughtful in expression, knows the issues, and listens well, and will no doubt discuss what he hears back to the other core CentOS developers; I trust Dag and Axel's instincts as well, and imagine they will discuss what they heard being said. I too 'listen', to this list, to IRC, to promises made and actions taken. One parting thing to consider -- I think of what are referred to as 'third-party' packagers and archives, as instead 'Independent' packagers and archives -- Russ Herrold herrold at centos.org herrold at owlriver.com From nando at ccrma.Stanford.EDU Sat May 26 21:28:44 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sat, 26 May 2007 14:28:44 -0700 Subject: repotags proposal In-Reply-To: <7874d9dd0705201823kcf7f5e4v6bfd8624ba06612f@mail.gmail.com> References: <465051FB.3030604@leemhuis.info> <99B5637F-ADBE-4406-9B92-2CC255616890@cs.ucsb.edu> <7874d9dd0705201823kcf7f5e4v6bfd8624ba06612f@mail.gmail.com> Message-ID: <1180214924.20004.56.camel@cmn15.stanford.edu> On Sun, 2007-05-20 at 20:23 -0500, Michael Stahnke wrote: > On 5/20/07, Jeff Sheltren wrote: > > On May 20, 2007, at 9:49 AM, Thorsten Leemhuis wrote: > > > > > > The EPEL Steering Committee gives this agreement only as long as > > > following points are meet by the technical solution: > > > > > > * it must remain possible to simply copy spec files between Fedora > > > and > > > EPEL branches without modifications > > > > > > * no hacks to the buildsys or modifications to the rpms after their > > > initial creation > > > > > > * the repotag must be used my all packages > > > > > > * no abuse of the disttag > > > > > > > Hi Thorsten, thanks for the proposal. I think that using some macro, > > such as %{?repotag}, or even just %{?repo} would be a good start. It > > is very easy to implement, and the same specs could still be used in > > Fedora without any problems (AFAICS). Adding it to the dist tag does > > not make sense to me. However, I am curious to know why you are > > against some sort of patch to the build system? It seems that could > > also be a nice possible solution. > > > > Aside from my question about having the build system handle the > > repotag on its own, I am mostly > > +1 for your proposal. > Allow me to add a +1 for discussion of this. Working in an enterprise > where Admins sometimes pull packages from a variety of sources, having > a repo-tag helps me. Same from me, +1. [sorry for the delay, one week without email, now still in vacation but with dsl access and trying to catch up...] I don't really care about the tech details on how it is implemented. %{?repotag} sounds fine. As long as the end result is Release: containing the proper string all methods would be fine. [disclaimer: I'm the maintainer for Planet CCRMA and not only an end user] -- Fernando From Axel.Thimm at ATrpms.net Sun May 27 11:54:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 27 May 2007 13:54:03 +0200 Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: <4657FF97.4030902@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> Message-ID: <20070527115403.GG11952@neu.nirvana> On Sat, May 26, 2007 at 11:36:23AM +0200, Thorsten Leemhuis wrote: > Further: I'm actually so unhappy with the current situation that I'm > willing to invest even more work to get repotags in EPEL4 and EPEL5 and > will leave EPEL if we don't get them. This contradicts your own actions: It was you who was the main opponent to repotags. W/o your opposition repotags would had probably passed (same for no-fedora-usermgmt-in-RHEL). And the outcome of the repotags fiasco was predicted from the very start months ago: Much pain to the other repos, a signal of non-cooperation and so on. So nothing has factually changed, the pain was there, the other repos strongly disapprove of your choices and methods and were driven away. Reverting the decision on repotags (which is really dead now, you killed it) is not going to change that, and is a questionable method in itself. You either believe in cooexistence and respect the request by other repos for repotags or not. I've grown very suspicious of hidden agendas to rule the world. I know that the fact that EPEL now isolated itself and other projects not being interested in contributing to EPEL (much like EPEL also never planned to contribute back to other projects, it won't even cooperate at a lower level) was not really part of your plan, but it's the natural outcome if a project doesn't care to coexist with other projects in the same ecosphere, especially when it simply targets to walk over them. So, the rhetorical question is why the change of heart? Because you really changed your mind on the principal questions of how EPEL should interact with its peers, or due to people walking away and you would like to lure them back making some compromises you don't really believe in? I strongly think that what you expressed about EPEL vs the rest of the world on rpmfusion lists and here is still valid. > I'd even go a step further and say now that I'll leave EPEL if we > don't find a peaceful way of co-existence with Dag and Axel and > CentOS. Now, that's a hyperbole, and EPEL is exactly were you drove it to. You even had yourself crowned president of the project with the sole rights to issue votes (on the grounds of having such a messy voting like the repotag issue should not happen again, aka more pain to whoever tries to issue an unpopular vote like myself), shortcut decisions and the mission to discuss things off-public. Messing up a project and threatening to leave it and have others clean it up is not proper IMO. > Maybe we can even get back to the drawing boards and find a way to > cooperate. Sorry, no more thl-batteries. You used them all up and you know that I recently canceled myself out of two projects that meant a lot to me. I was a big believer of EPEL and even more so of rpmfusion, but after all a project is just made out of the people behind it, and by now I know that we two completely failed to manage *three* projects counting the kmdl debacle last year. Not to mention the mass rebuild and disttag discussions on the pure Fedora side of things. We are really on 180? different points of views to express it as objective as possible. A second chance is always appropriate in the FLOSS world, maybe sometimes a third as well, but when one starts thinking about a forth and fifth chance, then something is definitely wrong in the picture. > Please do not confuse opinions expressed by individuals with a general > "EPEL mentality". Sure, those people are part of EPEL, but in big groups > there are alway lot's of different opinions. That's why there were votes on these issues by the EPEL steering committee and there were almost unanimously (and in fact you should take me out of the votes to see the current mindset of the EPEL committee and you will find that almost all votes *were* unanimous). > So, as I said, I'm quite unhappy with the current EPEL state -- just as > Dag, Axel and some others are. > > I'd really like to find a way out of this mess. Dag (you are on LinuxTAG > afaik) and Axel (are you there or could we meet? maybe in the evenings > if that's easier for you), can we please meet one or two hours on > LinuxTag (Wednesday preferred) Sure, we can meet. I'm less optimistic on whether this will actually solve any issues, but I'm always open. I think a personal commitment to something like Tim Jackson's https://www.redhat.com/archives/epel-devel-list/2007-April/msg00159.html would had been a grounding stone, but it was just pushed (once again) away to the board or fesco (this time the fpc was lucky), and EPEL is in fact far beyond being able to comply to that Repository Community Collaboration Statement already (and the copy in the wiki was semantically changed to something else not even the orginal author agrees with). FWIW I won't hide the fact, that after the rpmfusion/EPEL fiasco I'm looking for a new project that I will have ATrpms and my RHEL related workload to flow into, and there are quite nice offerings. > and find a way out of this mess that afaics to a big part evolved > because mail communication sucks. I don't believe in putting the blame on electronic mail. Yes, it does allow things to escalate, and does so within a few hours. But these problems are here over *months*. So there was no space for miscommunication over that amount of time. > A real life meeting maybe could get this mess solved. I'd actually > would like to have someone around that could speak for CentOS, > too. But not much more people as stuff might get confusing and > unfruitful otherwise. > > Dag, Axel, what do you think? Let's meet. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Sun May 27 12:56:52 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 27 May 2007 14:56:52 +0200 (CEST) Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: <4657FF97.4030902@leemhuis.info> References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> Message-ID: On Sat, 26 May 2007, Thorsten Leemhuis wrote: > Dag, Axel, what do you think? I didn't need a mail for that, I was planning to talk to you anyhow :) The whole debate not only started completely wrong (my fault) it turned out in something that caused even more pain. Problem is that what is evident for us (Axel, me and others), is mostly new to most people in Fedora and EPEL. And the communication did not always reflect that where it should have. Mainly because I preconceived some things (which became true after the fact :)) Sure I'm interested to meet. Remember that, contrary to FOSDEM, I plan to be at the booth after I promised it! So I prefer to hold meetings and extra activities outside of the exhibition hours. PS If required, we have a small appartement close to the LinuxTag fair that (at least on picture) looks big enough to host a handful of people. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ra+redhat at strg-alt-entf.org Sun May 27 13:11:04 2007 From: ra+redhat at strg-alt-entf.org (Ralph Angenendt) Date: Sun, 27 May 2007 15:11:04 +0200 Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> Message-ID: <20070527131104.GA22951@br-online.de> Dag Wieers wrote: > Sure I'm interested to meet. Remember that, contrary to FOSDEM, I plan to > be at the booth after I promised it! So I prefer to hold meetings and > extra activities outside of the exhibition hours. Ah well, noone is going to be all hours of all 4 days at the booth. So if you keep the meeting short (and have no bodycount), I don't see any problem :) Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Sun May 27 13:27:48 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 27 May 2007 15:27:48 +0200 (CEST) Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: <20070527131104.GA22951@br-online.de> References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> <20070527131104.GA22951@br-online.de> Message-ID: On Sun, 27 May 2007, Ralph Angenendt wrote: > Dag Wieers wrote: > > Sure I'm interested to meet. Remember that, contrary to FOSDEM, I plan to > > be at the booth after I promised it! So I prefer to hold meetings and > > extra activities outside of the exhibition hours. > > Ah well, noone is going to be all hours of all 4 days at the booth. So > if you keep the meeting short (and have no bodycount), I don't see any > problem :) Right, but that's where it started to go wrong, a 30min meeting takes 3 hours and one meeting becomes five meetings. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From lance at centos.org Mon May 28 15:40:45 2007 From: lance at centos.org (Lance Davis) Date: Mon, 28 May 2007 16:40:45 +0100 (BST) Subject: dag, axel somefrom from centos, let's please meet on LinuxTag (Re: Log from yesterdays (20070523) EPEL SIG meeting) In-Reply-To: References: <4655B3C7.4070002@leemhuis.info> <4657FF97.4030902@leemhuis.info> <20070527131104.GA22951@br-online.de> Message-ID: On Sun, 27 May 2007, Dag Wieers wrote: > On Sun, 27 May 2007, Ralph Angenendt wrote: > >> Dag Wieers wrote: >>> Sure I'm interested to meet. Remember that, contrary to FOSDEM, I plan to >>> be at the booth after I promised it! So I prefer to hold meetings and >>> extra activities outside of the exhibition hours. >> >> Ah well, noone is going to be all hours of all 4 days at the booth. So >> if you keep the meeting short (and have no bodycount), I don't see any >> problem :) > > Right, but that's where it started to go wrong, a 30min meeting takes 3 > hours and one meeting becomes five meetings. Surely that is partly what the time at the fair is for :) Outside exhibition hours is surely for drinking, eating, socialising, sleeping, and not discussing epel ... Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From fedora at leemhuis.info Mon May 28 18:34:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 28 May 2007 20:34:34 +0200 Subject: EPEL report week 20, 2007 Message-ID: <465B20BA.4070701@leemhuis.info> Hi all! Please find below this weeks EPEL report. It's also in the wiki at http://fedoraproject.org/wiki/EPEL/Reports/Week21 Cu knurd ---- = Weekly EPEL Summary = Week 21/2007 == Most important happenings == * [https://www.redhat.com/archives/epel-devel-list/2007-May/msg00138.html Noisy discussions] in reply to the meeting summary after the "repotags/interaction with 3rd party repos" topic was discussed and removed from the schedule; knurd will nevertheless bring it up in the next meeting again, as it was no formal discussion (only three Steering Committee members around then) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) (partly) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * dgilmore (DennisGilmore) * quiad (KarstenWade) Others that participated the meeting: LetoTo, Jeff_S, rdieter, f13, smooge === Summary === * 00:03 --- | knurd has changed the topic to: EPEL Meeting -- repotags/interaction with 3rd party repos -- owner: all * I'm not going to write a summary on this, as this is a very controversial and complicated topic. Sorry. Please read the full log. * 00:45 --- | mmcgrath has changed the topic to: EPEL Meeting -- Investigate single RHEL subscription for EPEL maintainers -- quaid * "It would be nice to get some RHEL subscriptions for our EPEL people though I think quaid has quite a journey ahead of him first. It may be easier once red hat can more easily realize the value of EPEL. knurd> | I don't think this is high on out todo list; we'll talk about this next time when quaid is around. * 00:49 --- | mmcgrath has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken * we need to look at converting epel to koji; f13> "there are some roadblocks to that. like koji modifications that would make the binaries used in the buildroots not publically available." * some discussions around RH management, using RHEL for Building and not CentOS * mbonnet will look into enabling koji to make use of a repo htat's not available to the public, which should make it possible to use koji for EPEL * lmacken> "bodhi would work with plague if we could get it filesystem access to the build results." ; he'll likely look into this, too, but making bodhi working for F7 is more important atm === Full meeting log === See https://www.redhat.com/archives/epel-devel-list/2007-May/msg00138.html == Stats == === General === Number of EPEL Contributors 80 We welcome 6 new contributors: ed_AT_eh3.com, jspaleta_AT_gmail.com, limb_AT_jcomserv.net, phuang_AT_redhat.com, pnemade_AT_redhat.com, tagoh_AT_redhat.com, zhu_AT_redhat.com === EPEL 5 === Number of source packages: 292 Number of binary packages: 470 There are 67 new Packages: * arp-scan | Scanning and fingerprinting tool * autodir | Creates user directories on demand * bugzilla | Bug tracking system * cgdb | CGDB is a curses-based interface to the GNU Debugger (GDB) * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * drgeo | Interactive educational geometry software * freehdl | GPLed free VHDL * gammu | Command Line utility to work with mobile phones * gperiodic | Program for browsing the periodic table * graphviz | Graph Visualization Tools * halberd | Tool to discover HTTP load balancers * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * incron | Inotify cron system * ircd-hybrid | Internet Relay Chat Server * jasper | Implementation of the JPEG-2000 standard, Part 1 * libiptcdata | IPTC tag library * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * ncarg | A Fortran and C based software package for scientific visualization * netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3) * nrpe | Host/service/network monitoring agent for Nagios * ocaml | Objective Caml compiler and programming environment * pdns | A modern, advanced and high performance authoritative-only nameserver * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Affix-Infix2Postfix | Perl extension for converting from infix notation to postfix notation * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-DBD-SQLite | Self Contained RDBMS in a DBI Driver * perl-HTML-Table | Create HTML tables using simple interface * perl-Image-Math-Constrain | Scaling math used in image size constraining (such as thumbnails) * perl-IO-Multiplex | IO-Multiplex module for perl * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Math-Base85 | Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-Net-Pcap | Interface to pcap(3) LBL packet capture library * perl-Nmap-Parser | Parse nmap scan data with perl * perl-Proc-Daemon | Run Perl program as a daemon process * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * php-channel-phpunit | Adds phpunit channel to PEAR * php-pear-DB | PEAR: Database Abstraction Layer * php-pear-Log | Abstracted logging facility for PHP * php-pear-Net-Ping | Execute ping * php-pear-Net-Traceroute | Execute traceroute * php-pecl-radius | Radius client library * php-pecl-xdebug | PECL package for debugging PHP scripts * plone | User friendly and powerful open source Content Management System * Pound | Reverse proxy and load balancer * python-cheetah | Template engine and code-generator * python-docutils | A system for processing plaintext documentation * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * python-protocols | Open Protocols and Component Adaptation for Python * python-sqlite2 | DB-API 2.0 interface for SQLite 3.x * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * ushare | UPnP (TM) A/V Media Server * windowlab | Small and Simple Amiga-like Window Manager * yum-arch | Extract headers from rpm in a old yum repository * zope | Web application server for flexible content management applications === EPEL 4 === Number of source packages: 194 Number of binary packages: 358 There are 36 new Packages: * bugzilla | Bug tracking system * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * drgeo | Interactive educational geometry software * freehdl | GPLed free VHDL * gperiodic | Program for browsing the periodic table * halberd | Tool to discover HTTP load balancers * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * ircd-hybrid | Internet Relay Chat Server * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * ncarg | A Fortran and C based software package for scientific visualization * netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3) * ocaml | Objective Caml compiler and programming environment * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-HTML-Table | Create HTML tables using simple interface * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Math-Base85 | Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-Nmap-Parser | Parse nmap scan data with perl * perl-Proc-Daemon | Run Perl program as a daemon process * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * Pound | Reverse proxy and load balancer * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * ushare | UPnP (TM) A/V Media Server * windowlab | Small and Simple Amiga-like Window Manager ---- ["CategoryEPELReports"] From fedora at leemhuis.info Tue May 29 14:49:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 29 May 2007 16:49:00 +0200 Subject: Likely no meeting this week Message-ID: <465C3D5C.4060909@leemhuis.info> Hi all! >From #epel on freenode: ---- knurd> | dgilmore, stahnma, quaid, nirik, do you want to run a meeting this week? mmcgrath and I will be on LinuxTag and likely not near a computer so it would be only you four from the steering committee dgilmore> | knurd: may be best to skip if people want to do it ill be happy to run it knurd> | sounds fine to me [...] quaid> | knurd_afk: I'm neutral; I can use the time constructively either way ---- So in other words: There likely won't be a meeting this week. If you want one just let us know. CU thl From buildsys at fedoraproject.org Wed May 30 21:16:58 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 30 May 2007 17:16:58 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-05-30 Message-ID: <20070530211658.7C24B152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 8 NEW dwatch-0.1.1-2.el5 : A program that watches over other programs NEW ettercap-0.7.3-19.el5 : Network traffic sniffer/analyser, NCURSES interface version gammu-1.11.0-1.el5 NEW gmrun-0.9.2-7.el5 : Lightweight "Run program" dialog box with search history and tab completion moin-1.5.8-1.el5 NEW perl-Net-Server-0.96-1.el5 : Extensible, general Perl server engine NEW vym-1.8.1-8.el5 : View your mind yumex-1.9.7-1.0.el5 Packages built and released for Fedora EPEL 4: 7 NEW dwatch-0.1.1-2.el4 : A program that watches over other programs NEW ettercap-0.7.3-19.el4 : Network traffic sniffer/analyser, NCURSES interface version NEW fontforge-20061025-1.el4 : Outline and bitmap font editor moin-1.5.8-1.el4 nfswatch-4.99.9-1.el4 NEW perl-Net-Server-0.96-1.el4 : Extensible, general Perl server engine NEW wine-0.9.36-1.el4 : A Windows 16/32/64 bit emulator Changes in Fedora EPEL 5: dwatch-0.1.1-2.el5 ------------------ * Thu May 24 2007 Bernard Johnson - 0.1.1-2 - fix dwatch.5 man page to use double quotes around argument * Wed May 23 2007 Bernard Johnson - 0.1.1-1 - initial release ettercap-0.7.3-19.el5 --------------------- * Wed Mar 28 2007 Jon Ciesla - 0.7.3-19 - /usr/bin/ettercap ownership fix. gammu-1.11.0-1.el5 ------------------ * Thu May 24 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.11.0-1 - Updated release. * Wed May 23 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.10.6-1 - Updated release. gmrun-0.9.2-7.el5 ----------------- * Sat Feb 10 2007 - 0.9.2-7 - Preserve the source time-stamp. moin-1.5.8-1.el5 ---------------- * Wed May 16 2007 Matthias Saou 1.5.8-1 - Update to 1.5.8, which includes most previous security fixes. - Remove the (apparently) no longer needed dos2unix conversion for patch. - Use %{python_sitelib} macro. perl-Net-Server-0.96-1.el5 -------------------------- * Fri May 18 2007 Kevin Fenzi - 0.96-1 - Update to 0.96 - Inital EL-5 build vym-1.8.1-8.el5 --------------- * Wed Mar 21 2007 Jon Ciesla - 1.8.1-8 - Converted patches to unified output format. yumex-1.9.7-1.0.el5 ------------------- * Tue May 29 2007 Tim Lauridsen - 1.9.7-1.0 - Development Release 1.9.7-1.0 Changes in Fedora EPEL 4: dwatch-0.1.1-2.el4 ------------------ * Thu May 24 2007 Bernard Johnson - 0.1.1-2 - fix dwatch.5 man page to use double quotes around argument * Wed May 23 2007 Bernard Johnson - 0.1.1-1 - initial release ettercap-0.7.3-19.el4 --------------------- * Wed Mar 28 2007 Jon Ciesla - 0.7.3-19 - /usr/bin/ettercap ownership fix. fontforge-20061025-1.el4 ------------------------ * Tue May 29 2007 Kevin Fenzi - 20061025-1 - Upgrade to 20061025-1 - Initial EL build moin-1.5.8-1.el4 ---------------- * Wed May 16 2007 Matthias Saou 1.5.8-1 - Update to 1.5.8, which includes most previous security fixes. - Remove the (apparently) no longer needed dos2unix conversion for patch. - Use %{python_sitelib} macro. nfswatch-4.99.9-1.el4 --------------------- * Wed May 30 2007 Christian Iseli 4.99.9-1 - new upstream version perl-Net-Server-0.96-1.el4 -------------------------- * Fri May 18 2007 Kevin Fenzi - 0.96-1 - Update to 0.96 - Inital EL build wine-0.9.36-1.el4 ----------------- * Sat May 05 2007 Andreas Bierfert 0.9.36-1 - version upgrade - minor fixes For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/