From orion at cora.nwra.com Wed Dec 5 22:22:01 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 05 Dec 2007 15:22:01 -0700 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <20071028114312.GC2634@free.fr> References: <20071021175544.GA23187@free.fr> <1192991022.22958.6.camel@localhost.localdomain> <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> <20071023100718.0e70d380@localhost.localdomain> <20071028114312.GC2634@free.fr> Message-ID: <47572489.3040602@cora.nwra.com> Patrice Dumas wrote: > On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote: >> So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? >> Does anyone have any technical objections to it? > > I have put a proposal here: > > https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir > > for consideration by the packaging commitee. > Did this ever get ratified? I'm starting to look at my .mod multiarch bugs... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From pertusus at free.fr Wed Dec 5 22:45:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Dec 2007 23:45:50 +0100 Subject: [Fedora-packaging] fortran .mod files In-Reply-To: <47572489.3040602@cora.nwra.com> References: <1193024435.25729.66.camel@mccallum.corsepiu.local> <471CCCD6.3060804@gmail.com> <20071022204912.GD2653@free.fr> <1193086248.22958.25.camel@localhost.localdomain> <1193110391.3693.17.camel@mccallum.corsepiu.local> <20071023111940.GV5451@devserv.devel.redhat.com> <1193140000.9342.60.camel@mccallum.corsepiu.local> <20071023100718.0e70d380@localhost.localdomain> <20071028114312.GC2634@free.fr> <47572489.3040602@cora.nwra.com> Message-ID: <20071205224550.GB2692@free.fr> On Wed, Dec 05, 2007 at 03:22:01PM -0700, Orion Poplawski wrote: > Patrice Dumas wrote: >> On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote: >>> So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? >>> Does anyone have any technical objections to it? >> >> I have put a proposal here: >> >> https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir >> >> for consideration by the packaging commitee. >> > > Did this ever get ratified? I'm starting to look at my .mod multiarch > bugs... It is ratified, I am waiting for https://bugzilla.redhat.com/show_bug.cgi?id=373861 to go and fix packages. -- Pat From ml at deadbabylon.de Mon Dec 10 12:56:51 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 10 Dec 2007 13:56:51 +0100 Subject: [Fedora-packaging] Best way of patching sources for changed libbeagle? Message-ID: <200712101356.55330.ml@deadbabylon.de> I need some help with the new libbeagle-0.3.0. This one is listed in pkg-config with "libbeagle-1.0". The configure script of kerry (and also brasero and yelp) are explicit checking for "libbeagle-0.0". Upstream hasn't catched up the new beagle, yet, so I have to figure out what is the best way of preparing my package (kerry) for the new libbeagle version. And here I need some help because I'm not very familiar with configure scripts. :) My attempt here is to avoid a patch and change the libbeagle version with sed: > %build > unset QTDIR || : ; . /etc/profile.d/qt.sh > export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include > > # libbeagle-version is now 0.1 > sed -i > 's/LIBBEAGLE_PACKAGES="libbeagle-0.0"/LIBBEAGLE_PACKAGES="libbeagle-1.0"/' > configure > > %configure --disable-rpath --disable-debug > make %{?_smp_mflags} A scratch build seems to be fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=285293 But I think there would be better options to to this. Sebastian -------------- 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 ml at deadbabylon.de Mon Dec 10 13:00:09 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 10 Dec 2007 14:00:09 +0100 Subject: [Fedora-packaging] Best way of patching sources for changed libbeagle? In-Reply-To: <200712101356.55330.ml@deadbabylon.de> References: <200712101356.55330.ml@deadbabylon.de> Message-ID: <200712101400.09384.ml@deadbabylon.de> Am Mo 10.Dezember 2007 schrieb Sebastian Vahl: > I need some help with the new libbeagle-0.3.0. This one is listed in > pkg-config with "libbeagle-1.0". The configure script of kerry (and also > brasero and yelp) are explicit checking for "libbeagle-0.0". > Upstream hasn't catched up the new beagle, yet, so I have to figure out > what is the best way of preparing my package (kerry) for the new libbeagle > version. And here I need some help because I'm not very familiar with > configure scripts. :) > > My attempt here is to avoid a patch and change the libbeagle version with sed: > > %build > > unset QTDIR || : ; . /etc/profile.d/qt.sh > > export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include > > > > # libbeagle-version is now 0.1 > > sed -i > > 's/LIBBEAGLE_PACKAGES="libbeagle-0.0"/LIBBEAGLE_PACKAGES="libbeagle-1.0"/ > >' configure > > > > %configure --disable-rpath --disable-debug > > make %{?_smp_mflags} > > A scratch build seems to be fine: > http://koji.fedoraproject.org/koji/taskinfo?taskID=285293 > > > But I think there would be better options to to this. > > Sebastian Oh. I've forgotten to copy the part from the configure script: > # LIBBEAGLE_CFLAGS: cflags for compiling libbeagle dependant sources > # LIBBEAGLE_LIBADD: libbeagle libraries (-l options) > # LIBBEAGLE_LDFLAGS: flags containing path to libbeagle libraries (-L > options) > > LIBBEAGLE_PACKAGES="libbeagle-0.0" > LIBBEAGLE_VERSION="0.2.5" > { echo "$as_me:$LINENO: checking for libbeagle-0.2.5 (at least > $LIBBEAGLE_VERSION)" >&5 echo $ECHO_N "checking for libbeagle-0.2.5 (at > least $LIBBEAGLE_VERSION)... $ECHO_C" >&6; } > > if $PKG_CONFIG --atleast-pkgconfig-version 0.15 ; then > if $PKG_CONFIG --atleast-version $LIBBEAGLE_VERSION $LIBBEAGLE_PACKAGES > >/dev/null 2>&1 ; then LIBBEAGLE_CFLAGS="`$PKG_CONFIG --cflags > $LIBBEAGLE_PACKAGES`" LIBBEAGLE_LIBADD="`$PKG_CONFIG --libs-only-l > --libs-only-other $LIBBEAGLE_PACKAGES`" LIBBEAGLE_LDFLAGS="`$PKG_CONFIG > --libs-only-L $LIBBEAGLE_PACKAGES`" { echo "$as_me:$LINENO: result: yes" > >&5 > echo "${ECHO_T}yes" >&6; } > fi > else > if $PKG_CONFIG --atleast-version $LIBBEAGLE_VERSION $LIBBEAGLE_PACKAGES > >/dev/null 2>&1 ; then LIBBEAGLE_CFLAGS="`$PKG_CONFIG --cflags > $LIBBEAGLE_PACKAGES`" LIBBEAGLE_LIBADD="`$PKG_CONFIG --libs-only-l > $LIBBEAGLE_PACKAGES`" LIBBEAGLE_LDFLAGS="`$PKG_CONFIG --libs-only-L > $LIBBEAGLE_PACKAGES`" { echo "$as_me:$LINENO: result: yes" >&5 > echo "${ECHO_T}yes" >&6; } > { echo "$as_me:$LINENO: WARNING: you may need to run make > LDFLAGS=-pthread to compile arts" >&5 echo "$as_me: WARNING: you may need > to run make LDFLAGS=-pthread to compile arts" >&2;} fi > fi > > if test -z "$LIBBEAGLE_LIBADD"; then > { echo "$as_me:$LINENO: result: not installed" >&5 > echo "${ECHO_T}not installed" >&6; } > DO_NOT_COMPILE="$DO_NOT_COMPILE kerry gmcop" > fi -------------- 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 tcallawa at redhat.com Mon Dec 10 16:35:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 10 Dec 2007 11:35:40 -0500 Subject: [Fedora-packaging] Best way of patching sources for changed libbeagle? In-Reply-To: <200712101356.55330.ml@deadbabylon.de> References: <200712101356.55330.ml@deadbabylon.de> Message-ID: <1197304540.6140.31.camel@localhost.localdomain> On Mon, 2007-12-10 at 13:56 +0100, Sebastian Vahl wrote: > I need some help with the new libbeagle-0.3.0. This one is listed in > pkg-config with "libbeagle-1.0". The configure script of kerry (and also > brasero and yelp) are explicit checking for "libbeagle-0.0". > Upstream hasn't catched up the new beagle, yet, so I have to figure out what > is the best way of preparing my package (kerry) for the new libbeagle > version. And here I need some help because I'm not very familiar with > configure scripts. :) > > My attempt here is to avoid a patch and change the libbeagle version with sed: Seems fine. This is one of my pet-peeves with pkgconfig, by embedding a "ABI/API/Arbitrary random version" in the identifier name, it makes looking for the related values much much more difficult. Instead of just asking pkgconfig for libgtkhtml's libs/headers, I've got to check for libgtkhtml-3.14, then libgtkhtml-3.12, libgtkhtml-3.10, libgtkhtml-3.08, libgtkhtml-3.06, libgtkhtml-3.04, and so on, ad infinitum. To be fair, this isn't pkgconfig's fault, it's GNOME's fault, as it seems to be the one doing this. Evolution recently dropped this practice, one can only hope that the rest of GNOME follows. ~spot From fnasser at redhat.com Mon Dec 10 16:43:43 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Mon, 10 Dec 2007 11:43:43 -0500 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 Message-ID: <475D6CBF.3000802@redhat.com> Hi guys, We will be working on importing JPackage.org Tomcat 6 RPM into Fedora 9 (will be submitted as a new package). I'd like to keep the tomcat5 package around as well, as some people may want to use the old version still. The packages have versioned names so they can be installed in parallel. Would that be OK? Regards to all, Fernando From rc040203 at freenet.de Mon Dec 10 17:25:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 10 Dec 2007 18:25:30 +0100 Subject: [Fedora-packaging] Best way of patching sources for changed libbeagle? In-Reply-To: <1197304540.6140.31.camel@localhost.localdomain> References: <200712101356.55330.ml@deadbabylon.de> <1197304540.6140.31.camel@localhost.localdomain> Message-ID: <1197307530.19022.13.camel@beck.corsepiu.local> On Mon, 2007-12-10 at 11:35 -0500, Tom "spot" Callaway wrote: > On Mon, 2007-12-10 at 13:56 +0100, Sebastian Vahl wrote: > > I need some help with the new libbeagle-0.3.0. This one is listed in > > pkg-config with "libbeagle-1.0". The configure script of kerry (and also > > brasero and yelp) are explicit checking for "libbeagle-0.0". > > Upstream hasn't catched up the new beagle, yet, so I have to figure out what > > is the best way of preparing my package (kerry) for the new libbeagle > > version. And here I need some help because I'm not very familiar with > > configure scripts. :) > > > > My attempt here is to avoid a patch and change the libbeagle version with sed: > > Seems fine. This is one of my pet-peeves with pkgconfig, by embedding a > "ABI/API/Arbitrary random version" in the identifier name, it makes > looking for the related values much much more difficult. > > Instead of just asking pkgconfig for libgtkhtml's libs/headers, I've got > to check for libgtkhtml-3.14, then libgtkhtml-3.12, libgtkhtml-3.10, > libgtkhtml-3.08, libgtkhtml-3.06, libgtkhtml-3.04, and so on, ad > infinitum. What you say only applies if a library's API is backward compatible to its predecessor. > To be fair, this isn't pkgconfig's fault, it's GNOME's fault, as it > seems to be the one doing this. Right, if a library's upstream is "backward compatible" they shouldn't bump the *.pc's file name, but only the internal version number. > Evolution recently dropped this > practice, one can only hope that the rest of GNOME follows. This advice is short-sighted. Versioned *.pc are one way (another one is using a different PKG_CONFIG_PATH) to permit parallel installation of API incompatible packages. So my advice would be library upstreams not to tie their *.pc's file names to package versions, but to API-versions, instead. Ralf From a.badger at gmail.com Wed Dec 12 17:53:01 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 12 Dec 2007 09:53:01 -0800 Subject: [Fedora-packaging] Python Eggs addition: example%files Message-ID: <47601FFD.8040809@gmail.com> Hi all, I've created a new section for the Python Eggs Guidelines with examples of how to deal with the fact that Fedora 9 creates .egg-info for distutils and Fedora < 9 does not. Comments appreciated, I'd like to see these discussed and voted on for addition to Packaging/Python/Eggs at Tuesday's meeting. http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Wed Dec 12 19:08:48 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2007 13:08:48 -0600 Subject: [Fedora-packaging] Python Eggs addition: example%files In-Reply-To: <47601FFD.8040809@gmail.com> References: <47601FFD.8040809@gmail.com> Message-ID: This looks to me. Frankly I don't think we should need to go through the full bureaucratic process just to add some examples, because we should be adding as many useful examples as we can. Perhaps they shouldn't go into the main guidelines documents, though, as people tend to think those documents are too long as it is. - J< From tibbs at math.uh.edu Wed Dec 12 19:14:52 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2007 13:14:52 -0600 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 In-Reply-To: <475D6CBF.3000802@redhat.com> References: <475D6CBF.3000802@redhat.com> Message-ID: >>>>> "FN" == Fernando Nasser writes: FN> I'd like to keep the tomcat5 package around as well, as some FN> people may want to use the old version still. The packages have FN> versioned names so they can be installed in parallel. Would that FN> be OK? I don't see why that would be a problem, although I'm not really sure of the implications of how the parallel installations would interact with initscripts. I guess since tomcat 5 uses "tomcat5" for its initscript there wouldn't be any conflict, but is there any point to running both versions at the same time? Also, I can't help but point out that we still really need someone from (one of) the Java team(s) to help us write some Java guidelines. Without guidelines, review tickets for Java packages have been piling up, and it's taken me a lot of time just to get answers to basic questions that have cropped up during a package review. - J< From jkeating at redhat.com Wed Dec 12 19:24:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 14:24:42 -0500 Subject: [Fedora-packaging] Python Eggs addition: example%files In-Reply-To: <47601FFD.8040809@gmail.com> References: <47601FFD.8040809@gmail.com> Message-ID: <20071212142442.02e7d616@redhat.com> On Wed, 12 Dec 2007 09:53:01 -0800 Toshio Kuratomi wrote: > I've created a new section for the Python Eggs Guidelines with > examples of how to deal with the fact that Fedora 9 creates .egg-info > for distutils and Fedora < 9 does not. Comments appreciated, I'd > like to see these discussed and voted on for addition to > Packaging/Python/Eggs at Tuesday's meeting. > > http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs Looks good to me, helpful for those packaging python. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From devrim at CommandPrompt.com Wed Dec 12 19:39:51 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Wed, 12 Dec 2007 11:39:51 -0800 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 In-Reply-To: References: <475D6CBF.3000802@redhat.com> Message-ID: <1197488391.13243.5.camel@localhost.localdomain> Hi, On Wed, 2007-12-12 at 13:14 -0600, Jason L Tibbitts III wrote: > I guess since tomcat 5 uses "tomcat5" for its > initscript there wouldn't be any conflict, but is there any point to > running both versions at the same time? I think what Fernando proposes is ability to install both versions at the same time -- not running them at the same time, right? Yeah, they will conflict in the default port settings, etc, but this will probably not be an issue. Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- 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 fnasser at redhat.com Wed Dec 12 19:46:01 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 12 Dec 2007 14:46:01 -0500 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 In-Reply-To: <1197488391.13243.5.camel@localhost.localdomain> References: <475D6CBF.3000802@redhat.com> <1197488391.13243.5.camel@localhost.localdomain> Message-ID: <47603A79.1080501@redhat.com> Devrim G?ND?Z wrote: > Hi, > > On Wed, 2007-12-12 at 13:14 -0600, Jason L Tibbitts III wrote: >> I guess since tomcat 5 uses "tomcat5" for its >> initscript there wouldn't be any conflict, but is there any point to >> running both versions at the same time? > > I think what Fernando proposes is ability to install both versions at > the same time -- not running them at the same time, right? Yeah, they > will conflict in the default port settings, etc, but this will probably > not be an issue. > You actually can. You just need to config the ports to different numbers. One can run more than one instance of the same tomcat5 version BTW, it was added in one of the latest revisions. The installation of parallel versions of tomcat exists for several years already, that is why they are called tomcat3, tomcat4, tomcat5 and tomcat6 instead of just tomcat. It happens that we started shipping a tomcat5 in Fedora, so we never noticed that. Cheers, Fernando > Regards, > > > ------------------------------------------------------------------------ > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From tibbs at math.uh.edu Wed Dec 12 19:52:39 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2007 13:52:39 -0600 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 In-Reply-To: <47603A79.1080501@redhat.com> References: <475D6CBF.3000802@redhat.com> <1197488391.13243.5.camel@localhost.localdomain> <47603A79.1080501@redhat.com> Message-ID: >>>>> "FN" == Fernando Nasser writes: FN> You actually can. You just need to config the ports to different FN> numbers. Then there should be no issues having both packages in the repos and not conflicting. - J< From fnasser at redhat.com Wed Dec 12 19:51:08 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 12 Dec 2007 14:51:08 -0500 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 In-Reply-To: References: <475D6CBF.3000802@redhat.com> Message-ID: <47603BAC.8000604@redhat.com> Jason L Tibbitts III wrote: >>>>>> "FN" == Fernando Nasser writes: > > FN> I'd like to keep the tomcat5 package around as well, as some > FN> people may want to use the old version still. The packages have > FN> versioned names so they can be installed in parallel. Would that > FN> be OK? > > I don't see why that would be a problem, although I'm not really sure > of the implications of how the parallel installations would interact > with initscripts. I guess since tomcat 5 uses "tomcat5" for its > initscript there wouldn't be any conflict, but is there any point to > running both versions at the same time? > The applications may need changes to run in a different version. Also there are some pre-packaged things that one does not know how to re-config but still wants to run. Last but not least, some bits are BuildRequires and tomcat6 has a different level of the APIs. I wanted to give people at least a release or two to adapt any dependnecies. > Also, I can't help but point out that we still really need someone > from (one of) the Java team(s) to help us write some Java guidelines. > Without guidelines, review tickets for Java packages have been piling > up, and it's taken me a lot of time just to get answers to basic > questions that have cropped up during a package review. > I ti snot the guidelines that are missing. Several Java-related stuff have been discussed over the last couple of years. Sometimes long and painful threads: ask Jess or Spot. What we need is people to do the reviews. We only get volunteers when someone is interested in a package (two cases recently). But nobody seems to have the cycle and we cannot review the packages we own ourselves. We need to try and get together some folks for a concentrate effort like we did once. Regards, Fernando From tibbs at math.uh.edu Wed Dec 12 19:57:37 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2007 13:57:37 -0600 Subject: [Fedora-packaging] Heads up: tomcat6 package into Fedora 9 In-Reply-To: <47603BAC.8000604@redhat.com> References: <475D6CBF.3000802@redhat.com> <47603BAC.8000604@redhat.com> Message-ID: >>>>> "FN" == Fernando Nasser writes: FN> I ti snot the guidelines that are missing. Well.... FN> What we need is people to do the reviews. I have been willing to review Java packages, but there are no guidelines which govern this and some of the practices I've seen in the packages (like the javadoc scriptlets) which I simply cannot approve without seeing a document that went through the guideline procedure saying "yes, it looks terrible but it's OK for Fedora". So many of those packages would have been reviewed were it not for the lack of guidelines. - J< From tibbs at math.uh.edu Tue Dec 18 18:28:03 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Dec 2007 12:28:03 -0600 Subject: [Fedora-packaging] Next FPC meeting: 2008-01-08? Message-ID: The next FPC meeting would normally fall on new year's day, 2008-01-01, which is not a good date for many, and one week before is obviously out for most folks. So the current proposal is for January eighth, 2008-01-08. Current votes on #fedora-meeting are: racor: 08/01 would be fine with me tibbs: So +1 for January 8th, 2008-01-08. abadger1999: +1 lutter: +1 If anyone else has an opinion, please weigh in. - J< From tcallawa at redhat.com Tue Dec 18 19:00:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 18 Dec 2007 14:00:40 -0500 Subject: [Fedora-packaging] Next FPC meeting: 2008-01-08? In-Reply-To: References: Message-ID: <1198004440.31913.39.camel@localhost.localdomain> On Tue, 2007-12-18 at 12:28 -0600, Jason L Tibbitts III wrote: > The next FPC meeting would normally fall on new year's day, > 2008-01-01, which is not a good date for many, and one week before is > obviously out for most folks. So the current proposal is for January > eighth, 2008-01-08. Current votes on #fedora-meeting are: > > racor: 08/01 would be fine with me > tibbs: So +1 for January 8th, 2008-01-08. > abadger1999: +1 > lutter: +1 spot: +1 ~spot From jkeating at redhat.com Tue Dec 18 19:29:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 18 Dec 2007 14:29:54 -0500 Subject: [Fedora-packaging] Next FPC meeting: 2008-01-08? In-Reply-To: <1198004440.31913.39.camel@localhost.localdomain> References: <1198004440.31913.39.camel@localhost.localdomain> Message-ID: <20071218142954.27f8b91f@redhat.com> On Tue, 18 Dec 2007 14:00:40 -0500 "Tom \"spot\" Callaway" wrote: > > racor: 08/01 would be fine with me > > tibbs: So +1 for January 8th, 2008-01-08. > > abadger1999: +1 > > lutter: +1 > spot: +1 f13: +1 -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bradbell at seanet.com Wed Dec 19 15:22:24 2007 From: bradbell at seanet.com (Brad Bell) Date: Wed, 19 Dec 2007 07:22:24 -0800 Subject: [Fedora-packaging] Procedures question Message-ID: <47693730.3030309@seanet.com> Perhaps this is not the proper list for the question below. If so, would you please direct me to the proper place. I am new to Fedora packaging and am trying to work through the details for getting a package into the Fedora distribution. As per the instructions on http://fedoraproject.org/wiki/PackageMaintainers/Join I followed the steps: "Read the Guidlines", "Create a Bugzilla Accoun"t, "Join the important Mailing Lists", "Read Other Submissions", "Make a Package", "Upload Your package", "Create Your Review Request". Now I am "Watching for Feedback", but do not seem to have gotten any; see https://bugzilla.redhat.com/show_bug.cgi?id=416761 Did I make some mistake in the steps above that is causing the request to be ignored ? From rdieter at math.unl.edu Wed Dec 19 15:27:53 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Dec 2007 09:27:53 -0600 Subject: [Fedora-packaging] Procedures question In-Reply-To: <47693730.3030309@seanet.com> References: <47693730.3030309@seanet.com> Message-ID: <47693879.1010705@math.unl.edu> Brad Bell wrote: > Now I am "Watching for Feedback", but do not seem to have gotten any; see > https://bugzilla.redhat.com/show_bug.cgi?id=416761 > Did I make some mistake in the steps above that is causing the request > to be ignored ? Package reviews don't happen by themselves, it takes someone to step up to do the work. It's just that no has done that yet for you here. Perhaps you could lobby/ask-for help on some mailing lists, say fedora-devel? -- Rex From richardfearn at gmail.com Thu Dec 20 20:20:35 2007 From: richardfearn at gmail.com (Richard Fearn) Date: Thu, 20 Dec 2007 20:20:35 +0000 Subject: [Fedora-packaging] Correct name for php-pdb package? Message-ID: <212718d80712201220r57db0004s3deded64a370953d@mail.gmail.com> Hi, I have a quick question about package naming. I'd like to package php-pdb, which is a PHP library for manipulating Palm OS databases: http://php-pdb.sourceforge.net/ Since the name already starts with "php-", I'm not sure what the package should be called - "php-pdb" or "php-php-pdb". I did notice that the package for PHP-IDN is called php-idn, so I suspect I should call my package "php-pdb". Is that correct? Thanks, Richard Fearn From tcallawa at redhat.com Thu Dec 20 20:25:37 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 20 Dec 2007 15:25:37 -0500 Subject: [Fedora-packaging] Correct name for php-pdb package? In-Reply-To: <212718d80712201220r57db0004s3deded64a370953d@mail.gmail.com> References: <212718d80712201220r57db0004s3deded64a370953d@mail.gmail.com> Message-ID: <1198182337.3370.31.camel@localhost.localdomain> On Thu, 2007-12-20 at 20:20 +0000, Richard Fearn wrote: > Hi, > > I have a quick question about package naming. > > I'd like to package php-pdb, which is a PHP library for manipulating > Palm OS databases: > > http://php-pdb.sourceforge.net/ > > Since the name already starts with "php-", I'm not sure what the > package should be called - "php-pdb" or "php-php-pdb". > > I did notice that the package for PHP-IDN is called php-idn, so I > suspect I should call my package "php-pdb". Is that correct? Yes. There is no need for pointless redundancy. :) ~spot, Department of Redundancy Department From richardfearn at gmail.com Thu Dec 20 21:20:23 2007 From: richardfearn at gmail.com (Richard Fearn) Date: Thu, 20 Dec 2007 21:20:23 +0000 Subject: [Fedora-packaging] Package content question Message-ID: <212718d80712201320n736c0bdevf66f34a71b9a73be@mail.gmail.com> Hello, I've just been reading the "Code Vs Content" section of the "Packaging Guidelines" document: http://fedoraproject.org/wiki/Packaging/Guidelines There is a list of content which is permissable, but in that list it says "Example files... are not considered content". Does this mean that example files aren't content and shouldn't be included, or does it mean that they're code rather than content and can be included? (php-pdb includes various sample files as part of its documentation, and I'm unsure whether they can be included or not.) Thanks Richard Fearn From dominik at greysector.net Thu Dec 20 21:50:27 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 20 Dec 2007 22:50:27 +0100 Subject: [Fedora-packaging] Package content question In-Reply-To: <212718d80712201320n736c0bdevf66f34a71b9a73be@mail.gmail.com> References: <212718d80712201320n736c0bdevf66f34a71b9a73be@mail.gmail.com> Message-ID: <20071220215027.GF3017@ryvius.greysector.net> On Thursday, 20 December 2007 at 22:20, Richard Fearn wrote: > Hello, > > I've just been reading the "Code Vs Content" section of the "Packaging > Guidelines" document: > > http://fedoraproject.org/wiki/Packaging/Guidelines > > There is a list of content which is permissable, but in that list it > says "Example files... are not considered content". > > Does this mean that example files aren't content and shouldn't be > included, or does it mean that they're code rather than content and > can be included? They may be included as %doc or in a separate subpackage if their size makes up a significant portion of the main package. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From richardfearn at gmail.com Thu Dec 20 22:45:47 2007 From: richardfearn at gmail.com (Richard Fearn) Date: Thu, 20 Dec 2007 22:45:47 +0000 Subject: [Fedora-packaging] Package content question In-Reply-To: <20071220215027.GF3017@ryvius.greysector.net> References: <212718d80712201320n736c0bdevf66f34a71b9a73be@mail.gmail.com> <20071220215027.GF3017@ryvius.greysector.net> Message-ID: <212718d80712201445o1eed70e0p2c7866767fba4f83@mail.gmail.com> Thanks for your help Dominik. > They may be included as %doc or in a separate subpackage if their size > makes up a significant portion of the main package. I have a few more questions regarding the documentation. The upstream developer of php-pdb has written his documentation as PHP scripts, for two reasons: 1. there are some basic template functions in each page (StandardHeader, StandardFooter, etc.) 2. some of the doc files are actually examples - which use the php-pdb library to generate database files. Is this a good reason for not including *any* of the documentation with my php-pdb package? If the files just get placed into /usr/share/doc/php-pdb-1.3.4 then they can't be viewed unless Apache is serving the files somehow. Or should I be doing more to make sure they are readable? (Such as converting the PHP scripts to static HTML files?) Are there any other packages that supply documentation in the form of PHP scripts as opposed to text or HTML files? The docs also include a .tar.gz containing a patched version of the php-pdb library, used to add export functionality to another program. It's not really an example - it's an alternative version of php-pdb to be used with another program. I intend to remove it for the php-pdb package - is that the right thing to do? Finally, there's another .tar.gz included in the docs, which contains a sample app that is also part of the docs - but I think I'm going have to remove the unpacked app (and remove links and references to it in the remaining doc files), because it can't run from inside /usr/share/doc (it would need write access to /usr/share/doc/php-pdb-1.3.4/samples/spade). Is it OK to leave the .tar.gz there as a sample app, though? Thanks. Richard Fearn From Axel.Thimm at ATrpms.net Fri Dec 28 21:08:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Dec 2007 23:08:46 +0200 Subject: [Fedora-packaging] Executable "Source:"es Message-ID: <20071228210846.GA399@puariko.nirvana> Hi, maybe not an FPC question, but I'll have a go: Since F9 Sources in the CVS "lost" their permission bit. For example the nx specfile has | Source11: nxfind-provides.sh | | %define _use_internal_dependency_generator 0 | %define __find_provides %{SOURCE11} a classical approach when one needs to extend/alter the default automatic dependency calculations. How can I teach CVS/koji that my Source11 should please get its execution bit back on? I could mess around in the specfile with chmod on the sources in the %sourcedir or try to be a bit cleaner by copying around the script and messing with its permissions there, but I think that's all not really clean and a bad workaround in general confusing anyone reading through the specfile (or trying to maintain it ;) Now the FPC question: We had agreed that sources should be either 0644 or 0755, did this change for F9 and later? If not is this something to report on another list? Which one? Bugzilla perhaps against koji? If yes, would this be worth while sending out to fedora-devel-announce? Merry Xmas and enjoy the new year everyone! -- 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 ville.skytta at iki.fi Sat Dec 29 11:41:06 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 29 Dec 2007 13:41:06 +0200 Subject: [Fedora-packaging] Executable "Source:"es In-Reply-To: <20071228210846.GA399@puariko.nirvana> References: <20071228210846.GA399@puariko.nirvana> Message-ID: <200712291341.12602.ville.skytta@iki.fi> On Friday 28 December 2007, Axel Thimm wrote: > Hi, > > maybe not an FPC question, but I'll have a go: > > Since F9 Sources in the CVS "lost" their permission bit. For example > the nx specfile has > > | Source11: nxfind-provides.sh > | > | %define _use_internal_dependency_generator 0 > | %define __find_provides %{SOURCE11} > > a classical approach when one needs to extend/alter the default > automatic dependency calculations. > > How can I teach CVS/koji that my Source11 should please get its > execution bit back on? No idea, but personally I think relying on any other permissions to SourceX and PatchX than read is fragile[0] and should be avoided. Doesn't this work (note the "sh")? %define __find_provides sh %{SOURCE11} [0] In addition to this case, eg. using explicit permissions when SourceX are copied directly to the binary package payloads is a must. From Axel.Thimm at ATrpms.net Sun Dec 30 12:53:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 30 Dec 2007 14:53:47 +0200 Subject: [Fedora-packaging] Re: Executable "Source:"es In-Reply-To: <200712291341.12602.ville.skytta@iki.fi> References: <20071228210846.GA399@puariko.nirvana> <200712291341.12602.ville.skytta@iki.fi> Message-ID: <20071230125347.GA27062@puariko.nirvana> On Sat, Dec 29, 2007 at 01:41:06PM +0200, Ville Skytt? wrote: > On Friday 28 December 2007, Axel Thimm wrote: > > Hi, > > > > maybe not an FPC question, but I'll have a go: > > > > Since F9 Sources in the CVS "lost" their permission bit. For example > > the nx specfile has > > > > | Source11: nxfind-provides.sh > > | > > | %define _use_internal_dependency_generator 0 > > | %define __find_provides %{SOURCE11} > > > > a classical approach when one needs to extend/alter the default > > automatic dependency calculations. > > > > How can I teach CVS/koji that my Source11 should please get its > > execution bit back on? > > No idea, but personally I think relying on any other permissions to SourceX > and PatchX than read is fragile[0] and should be avoided. Doesn't this work > (note the "sh")? > > %define __find_provides sh %{SOURCE11} Thanks a lot, the workaround works. But still there is an issue - obviously the FPC never mandated such a change, either the infrastructure people made that decision for us or it's a bug. I wouldn't mind if the FPC would decide to do so, but I would mind if other instances silently force such decisions through simply by defacto methods. -- 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 bradbell at seanet.com Sun Dec 30 14:42:03 2007 From: bradbell at seanet.com (Brad Bell) Date: Sun, 30 Dec 2007 06:42:03 -0800 Subject: [Fedora-packaging] Contributor License Agreement (CLA) Message-ID: <4777AE3B.6050508@seanet.com> I would like to understand a special case with respect to the CLA. It is the case where the Fedora packager is also the copyright holder for the package being contributed. I am the original author and copyright holder for a package. That package is currently distributed with the GPLv2 license. If I sign the CLA and complete the package contribution, does this mean that the original upstream source would no longer covered by the GPLv2 license, but rather by the CLA ? From jkeating at redhat.com Sun Dec 30 15:19:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 30 Dec 2007 10:19:46 -0500 Subject: [Fedora-packaging] Contributor License Agreement (CLA) In-Reply-To: <4777AE3B.6050508@seanet.com> References: <4777AE3B.6050508@seanet.com> Message-ID: <20071230101946.0c1428ad@redhat.com> On Sun, 30 Dec 2007 06:42:03 -0800 Brad Bell wrote: > I would like to understand a special case with respect to the CLA. It > is the case where the Fedora packager is also the copyright holder > for the package being contributed. > > I am the original author and copyright holder for a package. That > package is currently distributed with the GPLv2 license. If I sign > the CLA and complete the package contribution, does this mean that > the original upstream source would no longer covered by the GPLv2 > license, but rather by the CLA ? No. The CLA does not and cannot alter the licensing of any work brought to Fedora. It is purely for the work done for Fedora by Fedora contributors, such as wiki entries, spec files (that aren't otherwise provided/licensed via upstream), documentation, etc... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: