From tibbs at math.uh.edu Fri Jul 1 00:13:54 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Jun 2005 19:13:54 -0500 Subject: clamd handicraft work In-Reply-To: <42C3AB91.6020900@redhat.com> (Warren Togami's message of "Thu, 30 Jun 2005 10:21:37 +0200") References: <20050630100524.1a45b781@localhost.localdomain> <42C3AB91.6020900@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> What we need instead are clamav-something packages containing the WT> /etc/rc.d/init.rd/ files, prepared for different specific uses of WT> clamd. See http://www.math.uh.edu/~tibbs/packages/clamav-exim for a ten-minute attempt. Here's the .spec; it's not very good at all but if someone thinks worthy of comments I'll clean it up. - J< Name: clamav-exim Version: 0.0 Release: 1%{?dist} Summary: An instance of clamav for use with the Exim MTA Group: Applications/File License: Public Domain Source0: clamd.exim-init Source1: clamd-exim.conf Source2: clamd-exim.logrotate Source3: clamd.exim-sysconfig BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: clamav-server %description This package contains the special files needed to start a server instance of clamav for use by the Exim mail transfer agent. %prep %build %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_var}/log mkdir -p $RPM_BUILD_ROOT%{_var}/run/clamd.exim mkdir -p $RPM_BUILD_ROOT%{_initrddir} mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/clamd.d mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig touch $RPM_BUILD_ROOT%{_var}/log/clamd-exim.log install -c -m 755 %{SOURCE0} $RPM_BUILD_ROOT%{_initrddir}/clamd.exim install -c -m 644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/clamd.d/exim.conf install -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/clamd-exim install -c -m 644 %{SOURCE3} $RPM_BUILD_ROOT%{_sysconfdir}/sysconfig/clamd.exim %clean rm -rf $RPM_BUILD_ROOT %post /sbin/chkconfig --add clamd.exim /sbin/service clamd.exim condrestart >> /dev/null exit 0 %preun if [ $1 = 0 ]; then /sbin/chkconfig --del clamd.exim /sbin/service clamd.exim stop >> /dev/null fi %files %defattr(-,root,root,-) %{_initrddir}/clamd.exim %{_sysconfdir}/clamd.d/exim.conf %{_sysconfdir}/logrotate.d/clamd-exim %{_sysconfdir}/sysconfig/clamd.exim %attr(-,exim,exim) %{_var}/log/clamd-exim.log %attr(-,exim,exim) %dir %{_var}/run/clamd.exim %changelog * Thu Jun 30 2005 Jason L Tibbitts III - 0.0-1 - Initial build From tibbs at math.uh.edu Fri Jul 1 00:19:36 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Jun 2005 19:19:36 -0500 Subject: clamd handicraft work In-Reply-To: (Jason L. Tibbitts, III's message of "Thu, 30 Jun 2005 19:13:54 -0500") References: <20050630100524.1a45b781@localhost.localdomain> <42C3AB91.6020900@redhat.com> Message-ID: >>>>> "JLT" == Jason L Tibbitts, writes: JLT> See http://www.math.uh.edu/~tibbs/packages/clamav-exim for a JLT> ten-minute attempt. Urgh; http://www.math.uh.edu/~tibbs/rpms/clamav-exim/ - J< From rc040203 at freenet.de Fri Jul 1 00:26:58 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 02:26:58 +0200 Subject: Request For Review: lout (was Re: rpm package of lout) In-Reply-To: <1120159354.8990.15.camel@localhost.localdomain> References: <1120133730.2987.17.camel@localhost.localdomain> <42C3EC62.10507@linux-kernel.at> <1120141544.2513.194.camel@localhost.localdomain> <1120148641.3741.47.camel@mccallum.corsepiu.local> <1120159354.8990.15.camel@localhost.localdomain> Message-ID: <1120177618.3741.91.camel@mccallum.corsepiu.local> On Thu, 2005-06-30 at 14:22 -0500, Tom 'spot' Callaway wrote: > > New SPEC: http://www.auroralinux.org/people/spot/review/lout.spec > New SRPM: > http://www.auroralinux.org/people/spot/review/lout-3.30-2.src.rpm > > Please re-review Now, you're inconsistent with using directories. At some places you are using /usr/bin etc., at others %{_bindir} ... I'd propose this patch: --- lout.spec.2 2005-07-01 02:20:32.000000000 +0200 +++ lout.spec 2005-07-01 02:20:58.000000000 +0200 @@ -42,13 +42,13 @@ mkdir -p $RPM_BUILD_ROOT/%{_datadir} mkdir -p $RPM_BUILD_ROOT/%{_mandir}/man1 make DESTDIR=$RPM_BUILD_ROOT \ - BINDIR=/usr/bin \ - LIBDIR=/usr/share/lout \ - DOCDIR=/usr/share/lout/doc \ - MANDIR=/usr/share/man/man1 \ + BINDIR=%{_bindir} \ + LIBDIR=%{_datadir}/lout \ + DOCDIR=%{_datadir}/lout/doc \ + MANDIR=%{_mandir}/man1 \ install installman installdoc -cp %{SOURCE1} $RPM_BUILD_ROOT/%{_datadir}/%{name}/doc -gunzip $RPM_BUILD_ROOT/%{_datadir}/%{name}/doc/user.ps.gz +cp %{SOURCE1} $RPM_BUILD_ROOT/%{_datadir}/lout/doc +gunzip $RPM_BUILD_ROOT/%{_datadir}/lout/doc/user.ps.gz %clean rm -rf $RPM_BUILD_ROOT Another minor nit: There are traces of a lout-devel package inside of the spec, but a *-devel package is not being built. > (or approve). Ahh! - Seems as if the approval policy has changed ... Ralf From bugs.michael at gmx.net Fri Jul 1 00:29:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 02:29:34 +0200 Subject: Request for review: wv2 In-Reply-To: <1120171962.8990.67.camel@localhost.localdomain> References: <42C27815.9080304@lowlatency.de> <42C31007.2020505@lowlatency.de> <42C3896D.9020708@lowlatency.de> <1120171962.8990.67.camel@localhost.localdomain> Message-ID: <20050701022934.25ab7d82.bugs.michael@gmx.net> > > http://fedora.lowlatency.de/review/wv2-0.2.2-3.src.rpm > > http://fedora.lowlatency.de/review/wv2.spec At the run-time/install-time front, the following output $ wv2-config --cflags -I/usr/include -I/usr/include/libgsf-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 asks for at least the following dependencies in wv2-devel: Requires: libgsf-devel glib2-devel libxml2-devel -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.12-1.1385_FC4 loadavg: 2.59 3.93 3.19 From bugs.michael at gmx.net Fri Jul 1 00:30:07 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 02:30:07 +0200 Subject: Request for review: libpqxx In-Reply-To: <1120172641.8990.76.camel@localhost.localdomain> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> Message-ID: <20050701023007.41a1c3c7.bugs.michael@gmx.net> > > http://fedora.lowlatency.de/review/libpqxx-2.5.4-2.src.rpm > > http://fedora.lowlatency.de/review/libpqxx.spec $ pqxx-config --libs -L/usr/lib -lpqxx -L/usr/lib -R/usr/lib -lpq The -R/usr/lib option here is a source of future trouble, as it sets an RPATH. The -lpq means that in libpqxx-devel "Requires: postgresql-devel" is needed for libpq.so As a rule of thumb: whenever a -devel package contains a foo-config executable or a pkg-config file, these are worth examining for dependencies on other -devel packages. If no foo-config program or pkg-config file is included, it may need more effort to examine included C/C++ headers for dependencies. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.12-1.1385_FC4 loadavg: 2.96 3.98 3.63 From tcallawa at redhat.com Fri Jul 1 00:33:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 30 Jun 2005 19:33:13 -0500 Subject: Request for review: libpqxx In-Reply-To: <20050701023007.41a1c3c7.bugs.michael@gmx.net> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> Message-ID: <1120177993.8990.88.camel@localhost.localdomain> On Fri, 2005-07-01 at 02:30 +0200, Michael Schwendt wrote: > > > http://fedora.lowlatency.de/review/libpqxx-2.5.4-2.src.rpm > > > http://fedora.lowlatency.de/review/libpqxx.spec > > $ pqxx-config --libs > -L/usr/lib -lpqxx -L/usr/lib -R/usr/lib -lpq > > The -R/usr/lib option here is a source of future trouble, as it > sets an RPATH. How did that squeak past the rpath check? ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Fri Jul 1 00:44:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 02:44:06 +0200 Subject: Request For Review: lout (was Re: rpm package of lout) In-Reply-To: <1120177618.3741.91.camel@mccallum.corsepiu.local> References: <1120133730.2987.17.camel@localhost.localdomain> <42C3EC62.10507@linux-kernel.at> <1120141544.2513.194.camel@localhost.localdomain> <1120148641.3741.47.camel@mccallum.corsepiu.local> <1120159354.8990.15.camel@localhost.localdomain> <1120177618.3741.91.camel@mccallum.corsepiu.local> Message-ID: <20050701024406.2bac0d4b.bugs.michael@gmx.net> On Fri, 01 Jul 2005 02:26:58 +0200, Ralf Corsepius wrote: > > (or approve). > Ahh! - Seems as if the approval policy has changed ... Changed? How? (FWIW, I'm not aware of any changes) From tcallawa at redhat.com Fri Jul 1 00:43:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 30 Jun 2005 19:43:19 -0500 Subject: Request For Review: lout (was Re: rpm package of lout) In-Reply-To: <1120177618.3741.91.camel@mccallum.corsepiu.local> References: <1120133730.2987.17.camel@localhost.localdomain> <42C3EC62.10507@linux-kernel.at> <1120141544.2513.194.camel@localhost.localdomain> <1120148641.3741.47.camel@mccallum.corsepiu.local> <1120159354.8990.15.camel@localhost.localdomain> <1120177618.3741.91.camel@mccallum.corsepiu.local> Message-ID: <1120178600.8990.93.camel@localhost.localdomain> On Fri, 2005-07-01 at 02:26 +0200, Ralf Corsepius wrote: > On Thu, 2005-06-30 at 14:22 -0500, Tom 'spot' Callaway wrote: > > > > > New SPEC: http://www.auroralinux.org/people/spot/review/lout.spec > > New SRPM: > > http://www.auroralinux.org/people/spot/review/lout-3.30-2.src.rpm > > > > Please re-review > > Now, you're inconsistent with using directories. At some places you are > using /usr/bin etc., at others %{_bindir} ... Fixed for consistent macro use. Get another Fedora Extras contributor or Red Hat engineer (but not yourself) to be the primary reviewer and the approver of your package. > Another minor nit: There are traces of a lout-devel package inside of > the spec, but a *-devel package is not being built. Fixed. > > (or approve). > Ahh! - Seems as if the approval policy has changed ... Actually, no. The policy says "Get another Fedora Extras contributor or Red Hat engineer (but not yourself) to be the primary reviewer and the approver of your package.". You've got CVS extras commit access, therefore, you can review and approve packages. I've even documented the basic steps to look for in a review here: http://fedoraproject.org/wiki/PackageReviewGuidelines So, here are the fixed SRPM and SPEC: SRPM: http://www.auroralinux.org/people/spot/review/lout-3.30-3.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/lout.spec Please review (and approve, if it passes review). ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 1 00:44:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 30 Jun 2005 19:44:23 -0500 Subject: Request For Review: lout (was Re: rpm package of lout) In-Reply-To: <1120178600.8990.93.camel@localhost.localdomain> References: <1120133730.2987.17.camel@localhost.localdomain> <42C3EC62.10507@linux-kernel.at> <1120141544.2513.194.camel@localhost.localdomain> <1120148641.3741.47.camel@mccallum.corsepiu.local> <1120159354.8990.15.camel@localhost.localdomain> <1120177618.3741.91.camel@mccallum.corsepiu.local> <1120178600.8990.93.camel@localhost.localdomain> Message-ID: <1120178663.8990.95.camel@localhost.localdomain> On Thu, 2005-06-30 at 19:43 -0500, Tom 'spot' Callaway wrote: > Get another Fedora Extras contributor or Red Hat engineer (but not > yourself) to be the primary reviewer and the approver of your package. Sorry. Koffice has apparently cooked my brain. I didn't really mean to paste this twice. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From andreas at bawue.net Fri Jul 1 00:59:37 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 1 Jul 2005 02:59:37 +0200 (CEST) Subject: Request for review: GNU barcode In-Reply-To: References: Message-ID: On Fri, 1 Jul 2005, Andreas Thienemann wrote: > > %description > > The package is meant to solve most needs in barcode creation with a > > conventional printer. It can create printouts for the conventional > > product tagging standards: UPC-A, UPC-E, EAN-13, EAN-8, ISBN, as well > > as a few other formats. Ouput is generated as either Postscript or > > Encapsulated Postscript. > > > > SPEC: http://home.bawue.de/~ixs/barcode/barcode.spec > > SRPM: http://home.bawue.de/~ixs/barcode/barcode-0.98-1.src.rpm Okay, third and final release. I just added the %{?epoch} tag to the requires of the -devel package. If anyone could take a look at the package and review/approve, I'd be glad. regards, andreas From andreas at bawue.net Fri Jul 1 01:35:29 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 1 Jul 2005 03:35:29 +0200 (CEST) Subject: Request for Review: dd_rescue Message-ID: Hello, this package has been up for grabs at http://fedoraproject.org/wiki/Extras/OrphanedPackages. I updated the package from fedora.us according to current standards. %description ddrescue is a utility similar to the system utility "dd" which copies data from a file or block device to another. ddrescue does however not abort on errors in the input file. This makes it suitable for rescuing data from media with errors, e.g. a disk with bad sectors. SPEC: http://home.bawue.de/~ixs/dd_rescue/dd_rescue.spec SRPM: http://home.bawue.de/~ixs/dd_rescue/dd_rescue-1.11-1.src.rpm rpmlint doesn't output anything, which is always a good sign. ;-D Anyone to review this? thx, andreas From wtogami at redhat.com Fri Jul 1 01:45:59 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 01 Jul 2005 03:45:59 +0200 Subject: Request for Review: dd_rescue In-Reply-To: References: Message-ID: <42C4A057.7040902@redhat.com> Andreas Thienemann wrote: > Hello, > > this package has been up for grabs at > http://fedoraproject.org/wiki/Extras/OrphanedPackages. > > I updated the package from fedora.us according to current standards. > > %description > ddrescue is a utility similar to the system utility "dd" which copies > data from a file or block device to another. ddrescue does however > not abort on errors in the input file. This makes it suitable for > rescuing data from media with errors, e.g. a disk with bad sectors. > > SPEC: http://home.bawue.de/~ixs/dd_rescue/dd_rescue.spec > SRPM: http://home.bawue.de/~ixs/dd_rescue/dd_rescue-1.11-1.src.rpm > This is already in the repository thus requires no review. Usually orphaned means it only needs an owner. You're now the owner. Warren From bugs.michael at gmx.net Fri Jul 1 01:49:05 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 03:49:05 +0200 Subject: Request for review: libpqxx In-Reply-To: <1120177993.8990.88.camel@localhost.localdomain> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> <1120177993.8990.88.camel@localhost.localdomain> Message-ID: <20050701034905.33f5a77b.bugs.michael@gmx.net> On Thu, 30 Jun 2005 19:33:13 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-01 at 02:30 +0200, Michael Schwendt wrote: > > > > http://fedora.lowlatency.de/review/libpqxx-2.5.4-2.src.rpm > > > > http://fedora.lowlatency.de/review/libpqxx.spec > > > > $ pqxx-config --libs > > -L/usr/lib -lpqxx -L/usr/lib -R/usr/lib -lpq > > > > The -R/usr/lib option here is a source of future trouble, as it > > sets an RPATH. > > How did that squeak past the rpath check? That one checks libraries (DSOs), not linker options in shell script code. From bugs.michael at gmx.net Fri Jul 1 01:52:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 03:52:57 +0200 Subject: Request for review: GNU barcode In-Reply-To: References: Message-ID: <20050701035257.0cd0dd77.bugs.michael@gmx.net> On Fri, 1 Jul 2005 02:59:37 +0200 (CEST), Andreas Thienemann wrote: > On Fri, 1 Jul 2005, Andreas Thienemann wrote: > > > > %description > > > The package is meant to solve most needs in barcode creation with a > > > conventional printer. It can create printouts for the conventional > > > product tagging standards: UPC-A, UPC-E, EAN-13, EAN-8, ISBN, as well > > > as a few other formats. Ouput is generated as either Postscript or > > > Encapsulated Postscript. > > > > > > SPEC: http://home.bawue.de/~ixs/barcode/barcode.spec > > > SRPM: http://home.bawue.de/~ixs/barcode/barcode-0.98-1.src.rpm > Okay, third and final release. > > I just added the %{?epoch} tag to the requires of the -devel package. > > If anyone could take a look at the package and review/approve, I'd be > glad. Only clicked on above link and had a single look at your %{?epoch} and the bottom of the spec. Info files usually are added/removed into the info directory with install-info in %post/%postun scriptlets. From bugs.michael at gmx.net Fri Jul 1 01:55:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 03:55:55 +0200 Subject: Request for Review: dd_rescue In-Reply-To: References: Message-ID: <20050701035555.1b41f6c5.bugs.michael@gmx.net> On Fri, 1 Jul 2005 03:35:29 +0200 (CEST), Andreas Thienemann wrote: > Hello, > > this package has been up for grabs at > http://fedoraproject.org/wiki/Extras/OrphanedPackages. > > I updated the package from fedora.us according to current standards. > > %description > ddrescue is a utility similar to the system utility "dd" which copies > data from a file or block device to another. ddrescue does however > not abort on errors in the input file. This makes it suitable for > rescuing data from media with errors, e.g. a disk with bad sectors. > > SPEC: http://home.bawue.de/~ixs/dd_rescue/dd_rescue.spec > SRPM: http://home.bawue.de/~ixs/dd_rescue/dd_rescue-1.11-1.src.rpm > > rpmlint doesn't output anything, which is always a good sign. ;-D > > Anyone to review this? No need to review it. So far, apparently nobody wanted to take it. If you like to, request bugzilla component ownership in the Wiki (BugzillaAdmin page) and update the package in CVS if need be. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.12-1.1385_FC4 loadavg: 1.09 1.33 1.77 From andreas at bawue.net Fri Jul 1 02:06:26 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 1 Jul 2005 04:06:26 +0200 (CEST) Subject: Request for Review: dd_rescue In-Reply-To: <20050701035555.1b41f6c5.bugs.michael@gmx.net> References: <20050701035555.1b41f6c5.bugs.michael@gmx.net> Message-ID: On Fri, 1 Jul 2005, Michael Schwendt wrote: > No need to review it. So far, apparently nobody wanted to take it. If you > like to, request bugzilla component ownership in the Wiki (BugzillaAdmin > page) and update the package in CVS if need be. Thx. I wasn't completely sure about that. dd_rescue was in fedora.us and never in core, but the NewPackage process was referring to packages which were in core not needing a review. But hey, great. bye, andreas From wtogami at redhat.com Fri Jul 1 02:16:34 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 01 Jul 2005 04:16:34 +0200 Subject: CVSROOT modules,1.4108,1.4109 In-Reply-To: <200507010208.j6128cfH030139@cvs-int.fedora.redhat.com> References: <200507010208.j6128cfH030139@cvs-int.fedora.redhat.com> Message-ID: <42C4A782.10102@redhat.com> Andreas Thienemann wrote: > Author: ixs > > Update of /cvs/extras/CVSROOT > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30113 > > Modified Files: > modules > Log Message: > Added new module: dd_rescue > SNIP > +dd_rescue rpms/dd_rescue &common http://cvs.fedora.redhat.com/viewcvs/rpms/ddrescue/?root=extras ddrescue has been in Extras for years now, you have imported a duplicate a copy. I have no idea why the package is named ddrescue instead of dd_rescue though. Warren Togami wtogami at redhat.com From andreas at bawue.net Fri Jul 1 02:25:53 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 1 Jul 2005 04:25:53 +0200 (CEST) Subject: CVSROOT modules,1.4108,1.4109 (fwd) Message-ID: On Fri, 1 Jul 2005, Warren Togami wrote: > http://cvs.fedora.redhat.com/viewcvs/rpms/ddrescue/?root=extras > ddrescue has been in Extras for years now, you have imported a duplicate > a copy. I have no idea why the package is named ddrescue instead of > dd_rescue though. Simple. PackagingNaming Guide says: When naming packages for Fedora, the maintainer should use the dash '-' as the delimiter for name parts. The maintainer should NOT use an underscore '_', a plus '+', or a period '.' as a delimiter. _BUT_ packages where the upstream name naturally contains an underscore are excluded from this. As the upstream names his package dd_rescue, it should track the upstream name. Thus the former name was actually wrong. Just because debian does use it doesn't mean we should too. We are not using underscores as version delimiters. but what is the right way of renaming a package then? to the best of my knowledge cvs doesn't offer that functionality? regards, andreas From rdieter at math.unl.edu Fri Jul 1 03:24:38 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 30 Jun 2005 22:24:38 -0500 Subject: Request for review: koffice In-Reply-To: <42C46C17.3050805@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> Message-ID: Andreas Bierfert wrote: > koffice-1.4.0a: > KOffice - Integrated Office Suite > KOffice is a free, integrated office suite for KDE, the K Desktop Environment. > http://fedora.lowlatency.de/review/koffice.spec > http://fedora.lowlatency.de/review/koffice-1.4.0a-1.src.rpm For the love of all that is holy, please package the langpack files separately (altogether or separate src.rpm's I don't care, just as long as they are .noarch.rpm's), and follow upstream naming. -- Rex From rdieter at math.unl.edu Fri Jul 1 03:28:01 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 30 Jun 2005 22:28:01 -0500 Subject: Request for review: libpqxx In-Reply-To: <20050701023007.41a1c3c7.bugs.michael@gmx.net> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: >>>http://fedora.lowlatency.de/review/libpqxx-2.5.4-2.src.rpm >>>http://fedora.lowlatency.de/review/libpqxx.spec > > > $ pqxx-config --libs > -L/usr/lib -lpqxx -L/usr/lib -R/usr/lib -lpq > > The -R/usr/lib option here is a source of future trouble, as it > sets an RPATH. > > The -lpq means that in libpqxx-devel "Requires: postgresql-devel" is > needed for libpq.so I would venture to say that -lpq probably isn't even needed at all, as the libpqxx lib is (or *should* be) already linked to libpq. -- Rex From dennis at ausil.us Fri Jul 1 04:18:25 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 30 Jun 2005 23:18:25 -0500 Subject: build failure Message-ID: <200506302318.34588.dennis@ausil.us> I got notice of build failure of konversation error was on x86_64 checking for Qt... configure: error: Qt (>= Qt 3.2) (library qt-mt) not found. Please check your installation! For more details about this problem, look at the end of config.log. Make sure that you have compiled Qt with thread support! error: Bad exit status from /var/tmp/rpm-tmp.76230 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.76230 (%build) Qt on x86_64 should be there looks like it was ok on x86 and ppc. should i submit a new build request? -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Fri Jul 1 07:17:06 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 09:17:06 +0200 Subject: Build Result: rblcheck on development In-Reply-To: <20050630202948.5DD558029@extras64.linux.duke.edu> References: <20050630202948.5DD558029@extras64.linux.duke.edu> Message-ID: <42C4EDF2.5060203@linux-kernel.at> On 06/30/2005 10:29 PM, buildsys at fedoraproject.org wrote: > Build of rblcheck on development failed to complete on one or more archs. > Please see logs at: > http://extras64.linux.duke.edu/failed/development/rblcheck I'm a bit confused because of this. rblcheck uses libresolv, which is part of glibc, so it should be installed on extras64, shouldn't it? :-/ The error is here: [ ... ] checking for res_query... no checking for res_query in -lresolv... no checking for res_query in -lbind... no configure: error: cannot locate res_query function error: Bad exit status from /var/tmp/rpm-tmp.88683 (%build) [ ... ] I have no non-i386 machine (except alphas) available to test this package, so might someone have a look at this please... Best, Oliver From rc040203 at freenet.de Fri Jul 1 07:31:11 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 09:31:11 +0200 Subject: Request for review: perl-Number-Compare Message-ID: <1120203071.3741.98.camel@mccallum.corsepiu.local> Hi, This package is the first of a lengthy series of perl modules I'd like to see added to FE: perl-Number-Compare. %description Number::Compare compiles a simple comparison to an anonymous subroutine, which you can call with a value to be tested again. Files: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Number-Compare.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Number-Compare-0.01-1.src.rpm Review (and approval) appreciated, TIA Ralf From oliver at linux-kernel.at Fri Jul 1 07:35:24 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 09:35:24 +0200 Subject: New Package: fish In-Reply-To: <7dad0d77050630082771a9c706@mail.gmail.com> References: <7dad0d7705061701563c31edfd@mail.gmail.com> <42C10DC8.5050102@linux-kernel.at> <7dad0d770506290525164544d4@mail.gmail.com> <42C2B14D.9020308@linux-kernel.at> <7dad0d77050629113326ee1881@mail.gmail.com> <42C39CA8.4000501@linux-kernel.at> <7dad0d7705063006002d588057@mail.gmail.com> <20050630155603.3ca3ba35.bugs.michael@gmx.net> <7dad0d7705063007123486db7b@mail.gmail.com> <20050630170831.0358c922.bugs.michael@gmx.net> <7dad0d77050630082771a9c706@mail.gmail.com> Message-ID: <42C4F23C.3010007@linux-kernel.at> On 06/30/2005 05:27 PM, Axel Liljencrantz wrote: > On 6/30/05, Michael Schwendt wrote: >>On Thu, 30 Jun 2005 16:12:20 +0200, Axel Liljencrantz wrote: >> >> >>>>>http://roo.no-ip.org/fish/fedora/fish-1.11.1-8.src.rpm >>>> >>>>Repeating my earlier hint (%configure macro sets CFLAGS already, Makefile.in >>>>adds the other flags, make target "all" is default): >>> >>>Hmm, you are right, that is done automatically. But your patch changes >>>the CFLAGS part of the spec file back to the state it was in when I >>>originally submitted the package. I was told to change the CFLAGS >>>handling, and now I'm told to change it back to the way it was done in >>>the first place. Is this a disagreement on how the spec file should >>>look or an amusing method of confusing new packagers? :-o >> >>No, in your original packages you did _not_ use %configure. > > > Of course. The third option: I am confused. Given how common an > occurance it is, I really should learn to anticipate it. > > http://roo.no-ip.org/fish/fedora/fish-1.11.1-9.src.rpm Look OK for me now. Best, Oliver From oliver at linux-kernel.at Fri Jul 1 07:43:45 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 09:43:45 +0200 Subject: New package: icmpdn In-Reply-To: <1120141466.16588.56.camel@pc7.dolda2000.com> References: <1119962800.15326.39.camel@pc7.dolda2000.com> <42C151D4.9060800@linux-kernel.at> <1119968531.15326.61.camel@pc7.dolda2000.com> <20050628174717.65a55003.bugs.michael@gmx.net> <1119984945.15326.91.camel@pc7.dolda2000.com> <20050628212813.0d07a0a6.bugs.michael@gmx.net> <1120141466.16588.56.camel@pc7.dolda2000.com> Message-ID: <42C4F431.7050804@linux-kernel.at> On 06/30/2005 04:24 PM, Fredrik Tolf wrote: > On Tue, 2005-06-28 at 21:28 +0200, Michael Schwendt wrote: > >>>>You can override %configure's defaults like this: >>>> >>>> %configure --libdir=%{_lib} >>>>[...] >>>>Typo. Make it: >>>> >>>> %configure --libdir=/%{_lib} >>>> >>>>Note that on 64-bit multilib systems, the NSS modules are located >>>>in /lib64, not /lib. >>> >>>Does that mean that %{_lib} expands to only lib or lib64, and >>>not /usr/lib or anything of the kind? >> >>%_libdir expands to either /usr/lib or /usr/lib64 >>%_lib expands to either lib or lib64 > > > OK, it should be fixed now. > > >>Hmm, with Emacs' rpm-spec-mode and rpm-add-change-log-entry, I've never >>used a format used by %99 of the other packagers. Like: >> >>* Tue Jun 28 2005 Michael Schwendt >>- blubb >>- blibb >>- blobb > > I changed the format to that. > > >>>but I still don't know what this "PreReq" thingie is. >>>Is it a tag in the same sense as Source0? >> >>It's similar to "Requires:" and historically meant to imply that >>a dependency must be present before (="pre") your package would be >>installed. Only true RPM wizards, who hang out on rpm-list, could >>tell you, whether nowadays "PreReq:" is any different from "Requires:" >>or "Requires(pre):". >> >>Note, that when you do >> >>%post -p /sbin/ldconfig >>%postun -p /sbin/ldconfig >> >>You get an automatic dependency on /sbin/ldconfig and need not add any >>such Requires or Prereq yourself. >> >>Flag "-p /bin/something" means to make /bin/something the scriptlet >>interpreter instead of /bin/sh, and hence a dependency on /bin/something >>will be automatic. > > > I did just that. > > >>Or: Since %{_sysconfdir}/init.d is a soft-link with Fedora Core, not a >>directory, please use %{_sysconfdir}/rc.d/init.d/ or %{_initrddir}/init.d/ >>instead. Minor issue in Extras, would be a bigger one in Core. > > > It seems it was supposed to be just %{_initrddir}, rather than > %{_initrdddir}/init.d. > > Anyhow, new specfile and SRPM are at: > > > > > So what do you all think now? > > Thank you very much for your effort this far. A small patch to remove some unneeded empty lines in changelog and move %clean section before the files section, as we always have it this way: 43a44,46 > %clean > rm -rf "$RPM_BUILD_ROOT" > 59,61d61 < %clean < rm -rf "$RPM_BUILD_ROOT" < 64d63 < 71d69 < Everything else looks ok for me now. Best, Oliver From rc040203 at freenet.de Fri Jul 1 08:07:59 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 10:07:59 +0200 Subject: Request For Review: lout (was Re: rpm package of lout) In-Reply-To: <1120178600.8990.93.camel@localhost.localdomain> References: <1120133730.2987.17.camel@localhost.localdomain> <42C3EC62.10507@linux-kernel.at> <1120141544.2513.194.camel@localhost.localdomain> <1120148641.3741.47.camel@mccallum.corsepiu.local> <1120159354.8990.15.camel@localhost.localdomain> <1120177618.3741.91.camel@mccallum.corsepiu.local> <1120178600.8990.93.camel@localhost.localdomain> Message-ID: <1120205280.3741.106.camel@mccallum.corsepiu.local> On Thu, 2005-06-30 at 19:43 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-01 at 02:26 +0200, Ralf Corsepius wrote: > > On Thu, 2005-06-30 at 14:22 -0500, Tom 'spot' Callaway wrote: > So, here are the fixed SRPM and SPEC: > > SRPM: http://www.auroralinux.org/people/spot/review/lout-3.30-3.src.rpm > SPEC: http://www.auroralinux.org/people/spot/review/lout.spec > > Please review (and approve, if it passes review). Looks good, one minor nit, tough: # rpmlint lout-3.30-3.fc4.i386.rpm W: lout hidden-file-or-dir /usr/share/lout/doc/user/.pie_intr.swp Looks like a vim dump or similar to me ;) I am going to approve this package. Ralf From tian at c-sait.net Fri Jul 1 08:10:00 2005 From: tian at c-sait.net (Christian Jodar) Date: Fri, 1 Jul 2005 10:10:00 +0200 (CEST) Subject: [Fwd: Prep Error: gcfilms-5_2-1 on development] Message-ID: <48051.83.145.93.226.1120205400.squirrel@83.145.93.226> Hello, I got this error after having requested build of GCfilms 5.2 on devel: ---------------------------- Original Message ---------------------------- Object: Prep Error: gcfilms-5_2-1 on development From: buildsys at fedoraproject.org Date: Ven 1 juillet 2005 2:25 To: Tian at fedora.redhat.com -------------------------------------------------------------------------- could not find path /var/tmp/gcfilms-5_2-1h9-Gn7/rpms/gcfilms/devel for gcfilms-5_2-1. Any idea about the reasons for this problem? Does the build system use CVS tags? I was not able to tag the devel branch with the same one as for the FC-4 branch (which is a normal CVS behaviour). But I requested to build the same version as the FC-4 version (5.2.1). Could it explain the error? If it is the case, does this mean we can't deliver same versions on devel and FC-4? Thanks, Christian Jodar. From wtogami at redhat.com Fri Jul 1 08:26:44 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 01 Jul 2005 10:26:44 +0200 Subject: CVSROOT modules,1.4108,1.4109 (fwd) In-Reply-To: References: Message-ID: <42C4FE44.5010108@redhat.com> Andreas Thienemann wrote: > On Fri, 1 Jul 2005, Warren Togami wrote: > > >>http://cvs.fedora.redhat.com/viewcvs/rpms/ddrescue/?root=extras >>ddrescue has been in Extras for years now, you have imported a duplicate >>a copy. I have no idea why the package is named ddrescue instead of >>dd_rescue though. > > Simple. PackagingNaming Guide says: > > When naming packages for Fedora, the maintainer should use the dash '-' as > the delimiter for name parts. The maintainer should NOT use an underscore > '_', a plus '+', or a period '.' as a delimiter. > > _BUT_ > > packages where the upstream name naturally contains an underscore are > excluded from this. > > > As the upstream names his package dd_rescue, it should track the upstream > name. > Thus the former name was actually wrong. Just because debian does use it > doesn't mean we should too. We are not using underscores as version > delimiters. > > but what is the right way of renaming a package then? to the best of my > knowledge cvs doesn't offer that functionality? Upstream confuses the issue with their confusing naming calling it dd_rescue in some places but ddrescue in others. It seems to me that we should keep the existing package as-is in this case, because the package has been named ddrescue for years, and the binary is too named ddrescue. The guidelines exist for consistency going into the future, but it is too pedantic to force apply it to all existing packages. Just maintain the existing ddrescue package please. Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Fri Jul 1 08:36:29 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 11:36:29 +0300 Subject: ddrescue and dd_rescue (was: Re: CVSROOT modules,1.4108,1.4109 (fwd)) In-Reply-To: <42C4FE44.5010108@redhat.com> References: <42C4FE44.5010108@redhat.com> Message-ID: <1120206990.2815.222.camel@localhost.localdomain> On Fri, 2005-07-01 at 10:26 +0200, Warren Togami wrote: > Upstream confuses the issue with their confusing naming calling it > dd_rescue in some places but ddrescue in others. It seems to me that we > should keep the existing package as-is in this case, because the package > has been named ddrescue for years, and the binary is too named ddrescue. > > The guidelines exist for consistency going into the future, but it is > too pedantic to force apply it to all existing packages. Just maintain > the existing ddrescue package please. Before doing anything further, please see the thread below, discuss, and decide whether both ddrescue (GNU) and dd_rescue (the current one AFAIK) should be shipped, or only one of them. https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00782.html https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00915.html From rc040203 at freenet.de Fri Jul 1 09:00:45 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 11:00:45 +0200 Subject: Request for review: perl-Want Message-ID: <1120208445.3741.127.camel@mccallum.corsepiu.local> Hi, Another perl module: perl-Want. %description This module generalises the mechanism of the wantarray function, allowing a function to determine in some detail how its return value is going to be immediately used. Files: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm Review (and approval) appreciated, TIA Ralf From oliver at linux-kernel.at Fri Jul 1 09:26:36 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 11:26:36 +0200 Subject: Request for review: perl-Want In-Reply-To: <1120208445.3741.127.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> Message-ID: <42C50C4C.3060001@linux-kernel.at> Hi Ralf! On 07/01/2005 11:00 AM, Ralf Corsepius wrote: > Hi, > > Another perl module: perl-Want. > > %description > This module generalises the mechanism of the wantarray > function, allowing a function to determine in some detail > how its return value is going to be immediately used. > > Files: > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm > > Review (and approval) appreciated, TIA Is the license Artistic or is it GPL? The perl specfile template suggests the following for %install: rm -rf $RPM_BUILD_ROOT make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' chmod -R u+w $RPM_BUILD_ROOT/* Also it suggests the following for make: make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" The OPTIMIZE is missing in your spec. So I would suggest the following patch: 23c23 < make %{?_smp_mflags} --- > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" 27,33c27,29 < make install \ < PERL_INSTALL_ROOT=$RPM_BUILD_ROOT \ < INSTALLARCHLIB=$RPM_BUILD_ROOT%{perl_archlib} < < find $RPM_BUILD_ROOT -type f -a \( -name .packlist \ < -o -name perllocal.pod \ < -o \( -name '*.bs' -a -empty \) \) -exec rm -f {} ';' --- > make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT > find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' > find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' 34a31 > chmod -R u+w $RPM_BUILD_ROOT/* Best, Oliver From Christian.Iseli at licr.org Fri Jul 1 09:26:47 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 01 Jul 2005 11:26:47 +0200 Subject: Request for Approval: Nessus packages In-Reply-To: Your message of "Thu, 30 Jun 2005 02:21:41 -0000." <1120098101.7350.7.camel@fluffbox.fluffnet> Message-ID: <200507010926.j619QleY019402@ludwig-alpha.unil.ch> Hi Kyle, kapointer at charter.net said: > If someone would at least look at them I would greatly appreciate it. Ok, I started to have a look in libnasl :) Release: should not be fc4, but a number. The .fc4 will come when you add the %{?dist} macro when the package is approved. Source0: should contain a full URL (if possible) I do not think you need "Requires: nessus-libraries" and "Prereq: nessus-libraries". RPM should figure that out on its own. Since you have a "BuildPrereq: nessus-libraries", I suspect nessus-libraries should be split and contain a -devel part. Then you'd write: BuildRequires: nessus-libraries-devel (BuildRequires seems to be preferred over BuildPrereq) Canonical buildroot is: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %install should start with rm -rf ${RPM_BUILD_ROOT} %clean should contain rm -rf ${RPM_BUILD_ROOT} %post is empty and should be discarded, but since you add a shared library, you need: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig Please use macros instead of absolute pathnames (e.g., %{_bindir} instead of /usr/bin, etc.) Do not package libnasl.la (i.e., remove it in %install) Since you have a shared lib, there is in principle no need to also package libnasl.a Do not put manpages as %doc. Probably add some files in %doc (VERSION, COPYING, nasl_guide.tex, ...) Add version-release to your changelogs. Please update (also other nessus packages, suing the same ideas), and I'll re-review... Cheers, Christian From ville.skytta at iki.fi Fri Jul 1 09:31:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 12:31:38 +0300 Subject: Preliminary request for review: VDR Message-ID: <1120210298.2815.264.camel@localhost.localdomain> Note: it is not yet clear if this package passes the Extras legal requirements, examination already requested elsewhere. But I'm submitting a preliminary request for review here nevertheless because there is a biggish demand for packaged versions of VDR, and it is not impossible that reviewing this could take a while anyway. http://www.cadsoft.de/vdr/ VDR implements a complete digital set-top-box and video recorder. It can work with signals received from satellites (DVB-S) as well as cable (DVB-C) and terrestrial (DVB-T) signals. At least one DVB card is required to run VDR. Reviewer notes: First, this is not for the faint hearted. Successfully and sanely packaging this currently requires a pretty intimate knowledge of the software and experience in running it in "production". I'm up to the task; been watching TV at home exclusively through this beast since last October, and the package is now in a state where I'm fairly convinced that there's no need for incompatible packaging related changes in the foreseeable future. Starting to use this requires use of the dvb-apps package I submitted for review yesterday; the DVB channel configuration needs to be manually bootstrapped using the scandvb utility. Also, a properly set up "full featured" DVB card, ie. one containing a hardware MPEG decoder, is required to fully use this without any plugins [1]. As said, works for me, on i386. ppc(32) is excluded for now due to {get,put}_unaligned() not being available in its ; I believe this is a "bug" in VDR, not glibc-kernheaders (feel free to correct me if I'm wrong). See comments in the specfile for more info. x86_64 untested. And this is for FC4 and later only. Comments welcome, also in private mail; no "formal" review needed just yet. http://cachalot.mine.nu/4/SRPMS/vdr-1.3.27-0.8.src.rpm [1] If VDR gets a legal "nay" here, I'll submit this later to rpm.livna.org. Wherever it'll end up, I'll be submitting several plugins to appropriate repositories after the main package is "in", including some plugins that allow using this in a wider variety of setups in addition to the OOTB supported full featured DVB cards. The plugins are already on my site above. From Christian.Iseli at licr.org Fri Jul 1 09:31:44 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 01 Jul 2005 11:31:44 +0200 Subject: Request for Approval: Nessus packages In-Reply-To: Your message of "Fri, 01 Jul 2005 11:26:47 +0200." <200507010926.j619QleY019402@ludwig-alpha.unil.ch> Message-ID: <200507010931.j619ViAa019507@ludwig-alpha.unil.ch> I said: > Please update (also other nessus packages, suing the same ideas), s/suing/using/ whoops, Christian From paul at city-fan.org Fri Jul 1 09:32:00 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 10:32:00 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <1120203071.3741.98.camel@mccallum.corsepiu.local> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> Message-ID: <42C50D90.2000406@city-fan.org> Ralf Corsepius wrote: > This package is the first of a lengthy series of perl modules I'd like > to see added to FE: perl-Number-Compare. > > %description > Number::Compare compiles a simple comparison to an anonymous subroutine, > which you can call with a value to be tested again. > > Files: > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Number-Compare.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Number-Compare-0.01-1.src.rpm > > Review (and approval) appreciated, TIA Review: Good: - rpmlint silent - package naming meets naming guidelines - spec file name matches package name - package meets packaging guidelines - package has suitable license (Artistic or GPL) - spec file written in English and is legible, though I'd personally like to see the header fields line up... - source md5sums match upstream - builds OK for me on FC4 i386 - no explicit buildrequires needed - no locale data in package - no shared libraries in package - no relocations - directory ownership looks fine - no duplicate files - permissions fine - package has %clean section - no compiler optimization macros needed - package contains code, not content - documentation present and not excessively large - nothing in %doc affects runtime - no subpackages needed or present - no .la files included Bad: - license text not included in package. This is very common with perl modules and probably not really a blocker. The pod documentation clearly states "This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself." - use of macros not quite consistent, e.g. using %{__perl} but not %{__make} Suggestions: - I'd expand %description, to explain more the purpose of the module: Number::Compare compiles a simple comparison to an anonymous subroutine, which you can call with a value to be tested again. Now this would be very pointless, if Number::Compare didn't understand magnitudes. The target value may use magnitudes of kilobytes (k, ki), megabytes (m, mi), or gigabytes (g, gi). Those suffixed with an i use the appropriate 2**n version in accordance with the IEC standard: http://physics.nist.gov/cuu/Units/binary.html - I'd put %check after %install rather than after %clean, so that builds on rpm versions not supporting %check could still work. - I'd base %install on the template in fedora-rpmdevtools rather than the "old-fashioned" way using find. I don't see why a manual INSTALLARCHLIB setting should be necessary for a noarch package either. I'd like to hear further comments on the license text issue here. Paul. From paul at city-fan.org Fri Jul 1 09:36:07 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 10:36:07 +0100 Subject: Request for review: perl-Want In-Reply-To: <42C50C4C.3060001@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> Message-ID: <42C50E87.1050404@city-fan.org> Oliver Falk wrote: > Hi Ralf! > > On 07/01/2005 11:00 AM, Ralf Corsepius wrote: > >> Hi, >> >> Another perl module: perl-Want. >> >> %description >> This module generalises the mechanism of the wantarray >> function, allowing a function to determine in some detail >> how its return value is going to be immediately used. >> >> Files: >> ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec >> ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm >> >> Review (and approval) appreciated, TIA > > > Is the license Artistic or is it GPL? Both. The package is dual-licensed, as are many other perl modules. > The perl specfile template suggests the following for %install: > > rm -rf $RPM_BUILD_ROOT > make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT > find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' > find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' > find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' > chmod -R u+w $RPM_BUILD_ROOT/* > > Also it suggests the following for make: > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > > The OPTIMIZE is missing in your spec. He's set CFLAGS manually; I'd rather see it following the perl spec template too. Paul. From oliver at linux-kernel.at Fri Jul 1 09:44:10 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 11:44:10 +0200 Subject: Request for review: perl-Want In-Reply-To: <42C50E87.1050404@city-fan.org> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <42C50E87.1050404@city-fan.org> Message-ID: <42C5106A.8030109@linux-kernel.at> On 07/01/2005 11:36 AM, Paul Howarth wrote: > Oliver Falk wrote: >> On 07/01/2005 11:00 AM, Ralf Corsepius wrote: >> >>> Hi, >>> >>> Another perl module: perl-Want. >>> >>> %description >>> This module generalises the mechanism of the wantarray >>> function, allowing a function to determine in some detail >>> how its return value is going to be immediately used. >>> >>> Files: >>> ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec >>> ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm >>> >>> Review (and approval) appreciated, TIA >> >> Is the license Artistic or is it GPL? > > Both. The package is dual-licensed, as are many other perl modules. OK. Just wanted to be sure! >> The perl specfile template suggests the following for %install: >> >> rm -rf $RPM_BUILD_ROOT >> make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT >> find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' >> find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' >> find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' >> chmod -R u+w $RPM_BUILD_ROOT/* >> >> Also it suggests the following for make: >> make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" >> >> The OPTIMIZE is missing in your spec. > > He's set CFLAGS manually; I'd rather see it following the perl spec > template too. So, that's on his todo-list. :-) Best, Oliver From rc040203 at freenet.de Fri Jul 1 09:45:40 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 11:45:40 +0200 Subject: Request for review: perl-Want In-Reply-To: <42C50C4C.3060001@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> Message-ID: <1120211140.3741.139.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 11:26 +0200, Oliver Falk wrote: > Hi Ralf! > > On 07/01/2005 11:00 AM, Ralf Corsepius wrote: > > Hi, > > > > Another perl module: perl-Want. > > > > %description > > This module generalises the mechanism of the wantarray > > function, allowing a function to determine in some detail > > how its return value is going to be immediately used. > > > > Files: > > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec > > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm > > > > Review (and approval) appreciated, TIA > > Is the license Artistic or is it GPL? Have a look at the end of: http://search.cpan.org/src/ROBIN/Want-0.08/Want.pm It is the standard perl licence, i.e. "GPL or Artistic". > The perl specfile template suggests the following for %install: > > rm -rf $RPM_BUILD_ROOT > make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT > find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' > find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' > find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' > chmod -R u+w $RPM_BUILD_ROOT/* This would be a bit more general than what I use, but doesn't have any impact on this package's behavior. > Also it suggests the following for make: > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > > The OPTIMIZE is missing in your spec. Nope. It is set and is being used: ... Writing Makefile for Want + make cp Want.pm blib/lib/Want.pm /usr/bin/perl /usr/lib/perl5/5.8.6/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.6/ExtUtils/typemap Want.xs > Want.xsc && mv Want.xsc Want gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -DVERSION=\"0.08\" -DXS_VERSION=\"0.08\" -fPIC "-I/usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE" Want.c ... Ralf From paul at city-fan.org Fri Jul 1 10:05:29 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 11:05:29 +0100 Subject: Build Result: rblcheck on development In-Reply-To: <42C4EDF2.5060203@linux-kernel.at> References: <20050630202948.5DD558029@extras64.linux.duke.edu> <42C4EDF2.5060203@linux-kernel.at> Message-ID: <42C51569.2020100@city-fan.org> Oliver Falk wrote: > On 06/30/2005 10:29 PM, buildsys at fedoraproject.org wrote: > >> Build of rblcheck on development failed to complete on one or more archs. > > > Please see logs at: > >> http://extras64.linux.duke.edu/failed/development/rblcheck > > > I'm a bit confused because of this. rblcheck uses libresolv, which is > part of glibc, so it should be installed on extras64, shouldn't it? :-/ > > The error is here: > [ ... ] > checking for res_query... no > checking for res_query in -lresolv... no > checking for res_query in -lbind... no > configure: error: cannot locate res_query function > error: Bad exit status from /var/tmp/rpm-tmp.88683 (%build) > [ ... ] > > I have no non-i386 machine (except alphas) available to test this > package, so might someone have a look at this please... This is a common problem for packages that use res_query in libresolv. On x64_64 and possibly other architectures, res_query is defined as a macro in , and unless you include that header file in configure test for res_query, the macro won't get picked up, the actual name of the function won't be used and hence the test will fail at link time. Attached patch should fix it. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: rblcheck-1.5-res_query.patch Type: text/x-patch Size: 719 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jul 1 10:21:08 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 12:21:08 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C50D90.2000406@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> Message-ID: <1120213268.3741.159.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 10:32 +0100, Paul Howarth wrote: > Ralf Corsepius wrote: > > This package is the first of a lengthy series of perl modules I'd like > > to see added to FE: perl-Number-Compare. > > > > %description > > Number::Compare compiles a simple comparison to an anonymous subroutine, > > which you can call with a value to be tested again. > > > > Files: > > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Number-Compare.spec > > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Number-Compare-0.01-1.src.rpm > > > > Review (and approval) appreciated, TIA > > Review: > > Good: > - rpmlint silent > - package naming meets naming guidelines > - spec file name matches package name > - package meets packaging guidelines > - package has suitable license (Artistic or GPL) > - spec file written in English and is legible, though I'd personally > like to see the header fields line up... > - source md5sums match upstream > - builds OK for me on FC4 i386 > - no explicit buildrequires needed > - no locale data in package > - no shared libraries in package > - no relocations > - directory ownership looks fine > - no duplicate files > - permissions fine > - package has %clean section > - no compiler optimization macros needed > - package contains code, not content > - documentation present and not excessively large > - nothing in %doc affects runtime > - no subpackages needed or present > - no .la files included > > Bad: > - license text not included in package. This is very common with perl > modules and probably not really a blocker. The pod documentation clearly > states "This module is free software; you can redistribute it and/or > modify it under the same terms as Perl itself." Right, the license is included into Want.pm. > - use of macros not quite consistent, e.g. using %{__perl} but not %{__make} OK, I'll change this. > Suggestions: > > - I'd expand %description, to explain more the purpose of the module: > > Number::Compare compiles a simple comparison to an anonymous > subroutine, which you can call with a value to be tested again. Now > this would be very pointless, if Number::Compare didn't understand > magnitudes. The target value may use magnitudes of kilobytes (k, ki), > megabytes (m, mi), or gigabytes (g, gi). Those suffixed with an i use > the appropriate 2**n version in accordance with the IEC standard: > http://physics.nist.gov/cuu/Units/binary.html > > - I'd put %check after %install rather than after %clean, so that builds > on rpm versions not supporting %check could still work. I verified it works on FC3 and FC4 + inside of mock on FC4. > - I'd base %install on the template in fedora-rpmdevtools rather than > the "old-fashioned" way using find. I don't see why a manual > INSTALLARCHLIB setting should be necessary for a noarch package either. Probably true ... and don't actually care about it. I am using more or less the same spec file for about ca. 30 further modules. > I'd like to hear further comments on the license text issue here. I don't see a license issue. Want.pm contains: Copyright (c) 2001-2003, Robin Houston. All Rights Reserved. This module is free software. It may be used, redistributed and/or modified under the same terms as Perl itself. This is the standard perl license as being used by the perl package in FC: # rpm -q --qf '%{LICENSE}\n' perl Artistic or GPL Ralf From ville.skytta at iki.fi Fri Jul 1 10:28:11 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 13:28:11 +0300 Subject: Request for review: perl-Want In-Reply-To: <1120211140.3741.139.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> Message-ID: <1120213691.2815.273.camel@localhost.localdomain> On Fri, 2005-07-01 at 11:45 +0200, Ralf Corsepius wrote: > > Also it suggests the following for make: > > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > > > > The OPTIMIZE is missing in your spec. > Nope. It is set and is being used: No it's not, try eg. rebuilding with "--target i686" and watch -march. From paul at city-fan.org Fri Jul 1 10:31:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 11:31:30 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <1120213268.3741.159.camel@mccallum.corsepiu.local> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> Message-ID: <42C51B82.9020609@city-fan.org> Ralf Corsepius wrote: > On Fri, 2005-07-01 at 10:32 +0100, Paul Howarth wrote: >>- I'd put %check after %install rather than after %clean, so that builds >>on rpm versions not supporting %check could still work. > > I verified it works on FC3 and FC4 + inside of mock on FC4. It will do, because those versions have an rpm that supports %check. Some older versions of rpm don't, and it won't work on those. If you're not bothered about supporting them, you don't need the "|| :" after %check. > I don't see a license issue. > Want.pm contains: > > Copyright (c) 2001-2003, Robin Houston. All Rights Reserved. > This module is free software. It may be used, redistributed > and/or modified under the same terms as Perl itself. > > This is the standard perl license as being used by the perl package in FC: > # rpm -q --qf '%{LICENSE}\n' perl > Artistic or GPL The issue isn't the licenses themselves, it's that the text of the license isn't included in the package (and many other perl module packages). Paul. From oliver at linux-kernel.at Fri Jul 1 10:36:56 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 12:36:56 +0200 Subject: Request for review: perl-Want In-Reply-To: <1120211140.3741.139.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> Message-ID: <42C51CC8.4020309@linux-kernel.at> On 07/01/2005 11:45 AM, Ralf Corsepius wrote: > On Fri, 2005-07-01 at 11:26 +0200, Oliver Falk wrote: > >>Hi Ralf! >> >>On 07/01/2005 11:00 AM, Ralf Corsepius wrote: >> >>>Hi, >>> >>>Another perl module: perl-Want. >>> >>>%description >>>This module generalises the mechanism of the wantarray >>>function, allowing a function to determine in some detail >>>how its return value is going to be immediately used. >>> >>>Files: >>>ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec >>>ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm >>> >>>Review (and approval) appreciated, TIA >> >>Is the license Artistic or is it GPL? > > > Have a look at the end of: > http://search.cpan.org/src/ROBIN/Want-0.08/Want.pm > > It is the standard perl licence, i.e. "GPL or Artistic". Ok. >>The perl specfile template suggests the following for %install: >> >>rm -rf $RPM_BUILD_ROOT >>make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT >>find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' >>find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' >>find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' >>chmod -R u+w $RPM_BUILD_ROOT/* > > This would be a bit more general than what I use, but doesn't have any > impact on this package's behavior. It's just because the perl spec template does it this way, so I recommend it as well! >>Also it suggests the following for make: >>make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" >> >>The OPTIMIZE is missing in your spec. > > Nope. It is set and is being used: > > ... > Writing Makefile for Want > + make > cp Want.pm blib/lib/Want.pm > /usr/bin/perl /usr/lib/perl5/5.8.6/ExtUtils/xsubpp > -typemap /usr/lib/perl5/5.8.6/ExtUtils/typemap Want.xs > Want.xsc && mv > Want.xsc Want > gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing > -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -I/usr/include/gdbm -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -m32 -march=i386 -mtune=pentium4 > -fasynchronous-unwind-tables > -DVERSION=\"0.08\" -DXS_VERSION=\"0.08\" -fPIC > "-I/usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE" Want.c > ... As above, I just noted, that it's written this way in the template! Best, Oliver From oliver at linux-kernel.at Fri Jul 1 10:38:01 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 12:38:01 +0200 Subject: APPROVED: fish Message-ID: <42C51D09.9090000@linux-kernel.at> Name: fish Summary: A friendly interactive shell Description: fish is a shell geared towards interactive use. It's features are focused on user friendlieness and discoverability. The language syntax is simple but incompatible with other shell languages. Maintainer: Axel Liljencrantz Reviewer: Oliver Falk From wtogami at redhat.com Fri Jul 1 10:38:48 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 01 Jul 2005 12:38:48 +0200 Subject: ddrescue and dd_rescue In-Reply-To: <1120206990.2815.222.camel@localhost.localdomain> References: <42C4FE44.5010108@redhat.com> <1120206990.2815.222.camel@localhost.localdomain> Message-ID: <42C51D38.4050101@redhat.com> Ville Skytt? wrote: > On Fri, 2005-07-01 at 10:26 +0200, Warren Togami wrote: > > >>Upstream confuses the issue with their confusing naming calling it >>dd_rescue in some places but ddrescue in others. It seems to me that we >>should keep the existing package as-is in this case, because the package >>has been named ddrescue for years, and the binary is too named ddrescue. >> >>The guidelines exist for consistency going into the future, but it is >>too pedantic to force apply it to all existing packages. Just maintain >>the existing ddrescue package please. > > > Before doing anything further, please see the thread below, discuss, and > decide whether both ddrescue (GNU) and dd_rescue (the current one AFAIK) > should be shipped, or only one of them. > > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00782.html > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00915.html > Argh... my analysis above was based on only what I thought was overzealous adherence to guidelines used as justification for renaming a package. I had no idea there were TWO projects. I no longer care at all about this package. I don't have time to analyze this. I would suggest taking Steven Pritchard's analysis and looking at both upstream projects. Which seems better supported? Then choose one, then make sure appropriate Obsoletes and Provides are in place if the package name changes. Warren Togami wtogami at redhat.com From oliver at linux-kernel.at Fri Jul 1 10:42:49 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 12:42:49 +0200 Subject: Build Result: rblcheck on development In-Reply-To: <42C51569.2020100@city-fan.org> References: <20050630202948.5DD558029@extras64.linux.duke.edu> <42C4EDF2.5060203@linux-kernel.at> <42C51569.2020100@city-fan.org> Message-ID: <42C51E29.2090903@linux-kernel.at> Hi Paul! On 07/01/2005 12:05 PM, Paul Howarth wrote: > Oliver Falk wrote: > >> On 06/30/2005 10:29 PM, buildsys at fedoraproject.org wrote: >> >>> Build of rblcheck on development failed to complete on one or more >>> archs. >> >> >> > Please see logs at: >> >>> http://extras64.linux.duke.edu/failed/development/rblcheck >> >> >> >> I'm a bit confused because of this. rblcheck uses libresolv, which is >> part of glibc, so it should be installed on extras64, shouldn't it? :-/ >> >> The error is here: >> [ ... ] >> checking for res_query... no >> checking for res_query in -lresolv... no >> checking for res_query in -lbind... no >> configure: error: cannot locate res_query function >> error: Bad exit status from /var/tmp/rpm-tmp.88683 (%build) >> [ ... ] >> >> I have no non-i386 machine (except alphas) available to test this >> package, so might someone have a look at this please... > > > This is a common problem for packages that use res_query in libresolv. > On x64_64 and possibly other architectures, res_query is defined as a > macro in , and unless you include that header file in > configure test for res_query, the macro won't get picked up, the actual > name of the function won't be used and hence the test will fail at link > time. > > Attached patch should fix it. Thanks, I included it for release 10. Will commit it soon and request build again. Best, Oliver From andreas.bierfert at lowlatency.de Fri Jul 1 10:42:08 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 01 Jul 2005 12:42:08 +0200 Subject: Request for review: libpqxx In-Reply-To: <20050701023007.41a1c3c7.bugs.michael@gmx.net> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> Message-ID: <42C51E00.2010300@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > $ pqxx-config --libs > -L/usr/lib -lpqxx -L/usr/lib -R/usr/lib -lpq > > The -R/usr/lib option here is a source of future trouble, as it > sets an RPATH. Is that ok now: $ pqxx-config --libs - -L/usr/lib -lpqxx -L/usr/lib -lpq All other stuff mentioned by Tom is fixed as well :) http://fedora.lowlatency.de/review/libpqxx-2.5.4-3.src.rpm http://fedora.lowlatency.de/review/libpqxx.spec So is this ok for import/approval? > As a rule of thumb: whenever a -devel package contains a foo-config > executable or a pkg-config file, these are worth examining for dependencies > on other -devel packages. If no foo-config program or pkg-config file > is included, it may need more effort to examine included C/C++ headers > for dependencies. Is this a policy? I don't know... I reather would think if somebody needs to use the devel package that somebody would need to install the libs to and not do it automatically via Requires. That is why they where missing in the first place in my spec... I don't care one way or the other myself both is perfectly ok... it's just a question of consistancy between all packages... :) - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCxR4AQEQyPsWM8csRAiZKAKCssWzuJ8ZK8CYI2ywjaXcbhEQ71wCgtiez MtS7GeybZ1guApI2gw12LEw= =jMe2 -----END PGP SIGNATURE----- From andreas.bierfert at lowlatency.de Fri Jul 1 10:45:22 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 01 Jul 2005 12:45:22 +0200 Subject: Request for review: wv2 In-Reply-To: <1120171962.8990.67.camel@localhost.localdomain> References: <42C27815.9080304@lowlatency.de> <42C31007.2020505@lowlatency.de> <42C3896D.9020708@lowlatency.de> <1120171962.8990.67.camel@localhost.localdomain> Message-ID: <42C51EC2.1020100@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom 'spot' Callaway wrote: > The blockers are easy to resolve. If you fix them, I'll approve the > fixed spec file. done... maybe just let me mention the comment issue: My name in general is very long (at least in combination with the email addy). Thus I think the 80 chars per line limit is more important then having the version information on the same line. This has been an issue before and up till now (see my other packages) been ok with everybody... I changed it for wv2 an libpqxx because they stay unter 80 chars in a line (79). http://fedora.lowlatency.de/review/wv2-0.2.2-4.src.rpm http://fedora.lowlatency.de/review/wv2.spec Hope this is good for import/approval now. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCxR7BQEQyPsWM8csRAg6HAKCYm3qRh0GBEBwtD5/nYdSMwhCptACdGjDe OPTehQPD+kwncoY8wfF05kY= =hGI5 -----END PGP SIGNATURE----- From rc040203 at freenet.de Fri Jul 1 10:47:27 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 12:47:27 +0200 Subject: Request for review: perl-Want In-Reply-To: <1120213691.2815.273.camel@localhost.localdomain> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <1120213691.2815.273.camel@localhost.localdomain> Message-ID: <1120214847.3741.161.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 13:28 +0300, Ville Skytt? wrote: > On Fri, 2005-07-01 at 11:45 +0200, Ralf Corsepius wrote: > > > > Also it suggests the following for make: > > > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > > > > > > The OPTIMIZE is missing in your spec. > > Nope. It is set and is being used: > > No it's not, try eg. rebuilding with "--target i686" and watch -march. OK, I stand corrected. Updated files to be found (soon) at: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-2.src.rpm Ralf From andreas.bierfert at lowlatency.de Fri Jul 1 10:49:01 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 01 Jul 2005 12:49:01 +0200 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> Message-ID: <42C51F9D.5020503@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rex Dieter wrote: > For the love of all that is holy, please package the langpack files > separately (altogether or separate src.rpm's I don't care, just as long > as they are .noarch.rpm's), and follow upstream naming. Befor I do that... - - build of language stuff ties in with koffice nicely - - ooo langpack files are within the main package as well - - naming is exactly like ooo naming which IMHO is better for fedora users Just some points for you to understand why I did it this way. Any other comments on the more important parts of the spec file? - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCxR+dQEQyPsWM8csRApAdAJ4hVrTteqL1jNRfdabnvC5PwvDltwCeKhdb 8vrAoisBpSMEhwxuoKYsCjk= =vzHV -----END PGP SIGNATURE----- From rc040203 at freenet.de Fri Jul 1 10:50:34 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 12:50:34 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C51B82.9020609@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> <42C51B82.9020609@city-fan.org> Message-ID: <1120215034.3741.165.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 11:31 +0100, Paul Howarth wrote: > Ralf Corsepius wrote: > > On Fri, 2005-07-01 at 10:32 +0100, Paul Howarth wrote: > >>- I'd put %check after %install rather than after %clean, so that builds > >>on rpm versions not supporting %check could still work. > > > > I verified it works on FC3 and FC4 + inside of mock on FC4. > > It will do, because those versions have an rpm that supports %check. > Some older versions of rpm don't, and it won't work on those. If you're > not bothered about supporting them, you don't need the "|| :" after %check. Hmm, I need to think about it ... > > I don't see a license issue. > > Want.pm contains: > > > > Copyright (c) 2001-2003, Robin Houston. All Rights Reserved. > > This module is free software. It may be used, redistributed > > and/or modified under the same terms as Perl itself. > > > > This is the standard perl license as being used by the perl package in FC: > > # rpm -q --qf '%{LICENSE}\n' perl > > Artistic or GPL > > The issue isn't the licenses themselves, it's that the text of the > license isn't included in the package (and many other perl module packages). Well, ... I know, the GPL wants a package to be accompanied with a copy, but ... the author is pretty clear about his intention, so I don't see this as a problem. Ralf From andreas at bawue.net Fri Jul 1 10:53:25 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 1 Jul 2005 12:53:25 +0200 (CEST) Subject: ddrescue and dd_rescue In-Reply-To: <42C51D38.4050101@redhat.com> References: <42C4FE44.5010108@redhat.com> <1120206990.2815.222.camel@localhost.localdomain> <42C51D38.4050101@redhat.com> Message-ID: On Fri, 1 Jul 2005, Warren Togami wrote: > > decide whether both ddrescue (GNU) and dd_rescue (the current one AFAIK) > > should be shipped, or only one of them. > > > > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00782.html > > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00915.html > Argh... my analysis above was based on only what I thought was > overzealous adherence to guidelines used as justification for renaming a > package. I had no idea there were TWO projects. Argh is about right. ;) The problem was: we were shipping dd_rescue (the binary name) but the package was called ddrescue, to confuse matters. And this renaming could not be explained by adherence to some packaging naming scheme. It's a bit strange. > I no longer care at all about this package. I don't have time to > analyze this. I would suggest taking Steven Pritchard's analysis and > looking at both upstream projects. Which seems better supported? Then > choose one, then make sure appropriate Obsoletes and Provides are in > place if the package name changes. Yeah. I'll just testdrive both packages and we'll see which one is better. This one will be packaged. Luckily I do have a broken disk lying around to test it... bye, andreas From paul at city-fan.org Fri Jul 1 10:52:51 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 11:52:51 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <1120215034.3741.165.camel@mccallum.corsepiu.local> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> <42C51B82.9020609@city-fan.org> <1120215034.3741.165.camel@mccallum.corsepiu.local> Message-ID: <42C52083.5060303@city-fan.org> Ralf Corsepius wrote: > On Fri, 2005-07-01 at 11:31 +0100, Paul Howarth wrote: > >>Ralf Corsepius wrote: >>>I don't see a license issue. >>>Want.pm contains: >>> >>>Copyright (c) 2001-2003, Robin Houston. All Rights Reserved. >>>This module is free software. It may be used, redistributed >>>and/or modified under the same terms as Perl itself. >>> >>>This is the standard perl license as being used by the perl package in FC: >>># rpm -q --qf '%{LICENSE}\n' perl >>>Artistic or GPL >> >>The issue isn't the licenses themselves, it's that the text of the >>license isn't included in the package (and many other perl module packages). > > Well, ... > > I know, the GPL wants a package to be accompanied with a copy, but ... > the author is pretty clear about his intention, so I don't see this as a > problem. Neither do I; I was just seeking other opinions, because it conflicts with a MUST in the package review checklist and lots of existing packages have this issue. Paul. From rc040203 at freenet.de Fri Jul 1 11:00:31 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 13:00:31 +0200 Subject: Request for review: perl-Want In-Reply-To: <42C51CC8.4020309@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> Message-ID: <1120215631.3741.172.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 12:36 +0200, Oliver Falk wrote: > On 07/01/2005 11:45 AM, Ralf Corsepius wrote: > > On Fri, 2005-07-01 at 11:26 +0200, Oliver Falk wrote: > > This would be a bit more general than what I use, but doesn't have any > > impact on this package's behavior. > > It's just because the perl spec template does it this way, so I > recommend it as well! Let me put it this way: To me, all that matters is function. So, I am not going to adopt a template for stylish reasons, when I have something that "appears to work" for years. If others feel "slavishly hanging on to templates is a good thing", I am giving them "card blanche" to modify my perl-rpm-specs after cvs check in. Ralf From oliver at linux-kernel.at Fri Jul 1 11:05:30 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 13:05:30 +0200 Subject: Request for review: perl-Want In-Reply-To: <1120215631.3741.172.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> Message-ID: <42C5237A.6070306@linux-kernel.at> On 07/01/2005 01:00 PM, Ralf Corsepius wrote: > On Fri, 2005-07-01 at 12:36 +0200, Oliver Falk wrote: > >>On 07/01/2005 11:45 AM, Ralf Corsepius wrote: >> >>>On Fri, 2005-07-01 at 11:26 +0200, Oliver Falk wrote: > >>>This would be a bit more general than what I use, but doesn't have any >>>impact on this package's behavior. >> >>It's just because the perl spec template does it this way, so I >>recommend it as well! > > > Let me put it this way: To me, all that matters is function. > > So, I am not going to adopt a template for stylish reasons, when I have > something that "appears to work" for years. > > If others feel "slavishly hanging on to templates is a good thing", I am > giving them "card blanche" to modify my perl-rpm-specs after cvs check > in. It's your decision. :-) Best, Oliver From andreas at bawue.net Fri Jul 1 11:34:45 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 1 Jul 2005 13:34:45 +0200 (CEST) Subject: Request for review: GNU barcode In-Reply-To: <20050701035257.0cd0dd77.bugs.michael@gmx.net> References: <20050701035257.0cd0dd77.bugs.michael@gmx.net> Message-ID: On Fri, 1 Jul 2005, Michael Schwendt wrote: http://home.bawue.de/~ixs/barcode/barcode.spec > Only clicked on above link and had a single look at your %{?epoch} and the > bottom of the spec. Info files usually are added/removed into the info > directory with install-info in %post/%postun scriptlets. Ahh. Fixed. I bumped up the release. bye, andreas From ville.skytta at iki.fi Fri Jul 1 11:55:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 14:55:32 +0300 Subject: Request for review: libpqxx In-Reply-To: <42C51E00.2010300@lowlatency.de> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> <42C51E00.2010300@lowlatency.de> Message-ID: <1120218932.2815.294.camel@localhost.localdomain> On Fri, 2005-07-01 at 12:42 +0200, Andreas Bierfert wrote: > > As a rule of thumb: whenever a -devel package contains a foo-config > > executable or a pkg-config file, these are worth examining for dependencies > > on other -devel packages. If no foo-config program or pkg-config file > > is included, it may need more effort to examine included C/C++ headers > > for dependencies. > > Is this a policy? I don't know... I reather would think if somebody needs to use > the devel package that somebody would need to install the libs to and not do it > automatically via Requires. When one installs a package, dependencies should be there for all stuff that is needed to use the package, -devel or not. http://fedoraproject.org/wiki/PackagingGuidelines#head-2db2bd669d7a5a025a373a9aef588a85b1aa9eaf In the case of devel packages, "use" almost always means compiling stuff against the package. That includes using the output of foo-config or pkg-config foo.pc to determine the needed libs, CFLAGS and friends, as well as being able to #include header files from the package, use its *.m4 etc. Not doing so will lead to explicit dependency bloat and increased maintenance burden for all packages that use the -devel package in question. From jamatos at fc.up.pt Fri Jul 1 11:48:25 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 01 Jul 2005 12:48:25 +0100 Subject: Request for review: pygsl Message-ID: Hi, this is my first message here. I have been (GNU/)Linux exclusively for the last 9 years, after Slackware I have changed to Red Hat Linux 5.0 and from there I have updated the system to the latest Fedora. :-) I'm doing a PhD on econophysics (applying techniques from statistical physical to the study of financial time series) and I have contributed before to several free software projects, being the most import LyX where I am one of the core developers. Due to my work I have been interested and I have packaged for local consuption several scientific packages related with python and R. I have done all the process to become an FE packager. As a first step I propose for inclusion in FE pygsl. http://www.fc.up.pt/pessoas/jamatos/pygsl.spec http://www.fc.up.pt/pessoas/jamatos/pygsl-0.3.2-1.src.rpm Possible problem for this package: -Name: It already has py in its name is it necessary to change it to python-pygsl? -License: Although the project is GPL (it is clearly placed in the sources) there isn't no license in the source package. -FC3: This version of pygsl does not compile in FC3 since it links to wavelets that are only present in gsl 1.6. Also the previous version 0.3.1 doesn't compile in FC4. I have compile this using mock in i386 and x86_64 architecture without problems, the only complain of rpmlint is that: - there is no binary - several example files are not non executable scripts I think that these are harmless... -- Jos? Ab?lio From bugs.michael at gmx.net Fri Jul 1 12:06:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 14:06:42 +0200 Subject: [Fwd: Prep Error: gcfilms-5_2-1 on development] In-Reply-To: <48051.83.145.93.226.1120205400.squirrel@83.145.93.226> References: <48051.83.145.93.226.1120205400.squirrel@83.145.93.226> Message-ID: <20050701140642.77522b1d.bugs.michael@gmx.net> On Fri, 1 Jul 2005 10:10:00 +0200 (CEST), Christian Jodar wrote: > Hello, > > I got this error after having requested build of GCfilms 5.2 on devel: > > > ---------------------------- Original Message ---------------------------- > Object: Prep Error: gcfilms-5_2-1 on development > From: buildsys at fedoraproject.org > Date: Ven 1 juillet 2005 2:25 > To: Tian at fedora.redhat.com > -------------------------------------------------------------------------- > > could not find path /var/tmp/gcfilms-5_2-1h9-Gn7/rpms/gcfilms/devel for > gcfilms-5_2-1. > > > > > Any idea about the reasons for this problem? No, looks a bit like a cvs checkout path from the buildsys. > Does the build system use CVS tags? Yes, of course. That's what you see in the "tobuild" file, where you add tags with "make build". > I was not able to tag the devel branch > with the same one as for the FC-4 branch (which is a normal CVS behaviour). > But I requested to build the same version as the FC-4 version (5.2.1). Could > it explain the error? If it is the case, does this mean we can't deliver > same versions on devel and FC-4? Right. That's why you may need to add %{?dist} to your spec, as a) that makes "make tag" create a different tag for every branch, and b) makes the binary rpms also get a different release tag, so they upgrade eachother fine. You cannot have the same version-release for multiple distributions and arch-specific and dist-specific rpms, because that would violate the upgrade path. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.00 1.01 1.00 From bugs.michael at gmx.net Fri Jul 1 12:07:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 14:07:27 +0200 Subject: build failure In-Reply-To: <200506302318.34588.dennis@ausil.us> References: <200506302318.34588.dennis@ausil.us> Message-ID: <20050701140727.3eec4c10.bugs.michael@gmx.net> On Thu, 30 Jun 2005 23:18:25 -0500, Dennis Gilmore wrote: > I got notice of build failure of konversation error was on x86_64 > > checking for Qt... configure: error: Qt (>= Qt 3.2) (library qt-mt) not found. > Please check your installation! > For more details about this problem, look at the end of config.log. > Make sure that you have compiled Qt with thread support! > error: Bad exit status from /var/tmp/rpm-tmp.76230 (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.76230 (%build) > > Qt on x86_64 should be there looks like it was ok on x86 and ppc. should i > submit a new build request? It would give the same results. What you would need is a copy of the config.log, as most likely the configure script once again failed to find Qt in /usr/lib64/qt-3.3/lib and either looked in /usr/lib64/qt-3.3/lib64 or somewhere else. I've seen this before and fixed it in some packages, but I don't have an x86_64 machine for real experiments. For a trial-and-error fix attempt, try copying from amarok.spec, where I chose to set $QTLIB and $QTINC to make it build, so we could move on. If that doesn't fix it, a closer look might be necessary (also examining build behaviour in multilib installations). -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.01 1.12 1.00 From bugs.michael at gmx.net Fri Jul 1 12:08:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 14:08:51 +0200 Subject: Request for Review: dd_rescue In-Reply-To: References: <20050701035555.1b41f6c5.bugs.michael@gmx.net> Message-ID: <20050701140851.33e55a61.bugs.michael@gmx.net> On Fri, 1 Jul 2005 04:06:26 +0200 (CEST), Andreas Thienemann wrote: > On Fri, 1 Jul 2005, Michael Schwendt wrote: > > > No need to review it. So far, apparently nobody wanted to take it. If you > > like to, request bugzilla component ownership in the Wiki (BugzillaAdmin > > page) and update the package in CVS if need be. > Thx. > > I wasn't completely sure about that. dd_rescue was in fedora.us and never > in core, but the NewPackage process was referring to packages which were > in core not needing a review. > > But hey, great. It's not a new package. It's a package in Fedora Extras. Hence the NewPackageProcess doesn't cover this at all. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.09 1.21 1.00 From bugs.michael at gmx.net Fri Jul 1 12:09:12 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 14:09:12 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C50D90.2000406@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> Message-ID: <20050701140912.6d559b57.bugs.michael@gmx.net> On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: > - I'd put %check after %install rather than after %clean, so that builds > on rpm versions not supporting %check could still work. Does order of spec sections matter? (I don't think so) From rc040203 at freenet.de Fri Jul 1 12:23:57 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:23:57 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <20050701140912.6d559b57.bugs.michael@gmx.net> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> Message-ID: <1120220637.3741.187.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 14:09 +0200, Michael Schwendt wrote: > On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: > > > - I'd put %check after %install rather than after %clean, so that builds > > on rpm versions not supporting %check could still work. > > Does order of spec sections matter? (I don't think so) Neither do I, but I don't have anything older than FC3 available for testing. Ralf From andreas.bierfert at lowlatency.de Fri Jul 1 12:25:55 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 01 Jul 2005 14:25:55 +0200 Subject: Request for review: libpqxx In-Reply-To: <1120218932.2815.294.camel@localhost.localdomain> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> <42C51E00.2010300@lowlatency.de> <1120218932.2815.294.camel@localhost.localdomain> Message-ID: <42C53653.2000900@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > When one installs a package, dependencies should be there for all stuff > that is needed to use the package, -devel or not. > http://fedoraproject.org/wiki/PackagingGuidelines#head-2db2bd669d7a5a025a373a9aef588a85b1aa9eaf That is fine with me and I usually do so for non-devel packages (if I don't miss the occasional missing dep ;) ) but I thought for -devel this could/should be different. Thanks for the clarification. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCxTZTQEQyPsWM8csRAhkXAKCpZhEdDJqEQ10CLn8c9IX13eikaQCghxrZ UpE3QrSAnC8Sw4rE7SizqWI= =5gSj -----END PGP SIGNATURE----- From paul at city-fan.org Fri Jul 1 12:39:22 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 13:39:22 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <20050701140912.6d559b57.bugs.michael@gmx.net> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> Message-ID: <42C5397A.9010005@city-fan.org> Michael Schwendt wrote: > On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: > > >>- I'd put %check after %install rather than after %clean, so that builds >>on rpm versions not supporting %check could still work. > > > Does order of spec sections matter? (I don't think so) Current rpm versions run the %check scriptlet after %install, if %check is present. Older rpm versions don't understand %check, and will barf when they come across it. The standard idiom for working around this is to use: %check || : This causes old versions of rpm to ignore the fact that they don't understand %check and carry on whatever they were doing, which will be running the scriptlet immediately before %check. So if you want old versions of rpm to behave like new ones, you use this order: %install ... %check || : ... If instead you have: %install ... %clean ... %check || : ... then old versions of rpm will run the %check scriptlet at the end of the %clean scriptlet, i.e. just after everything has been deleted. Not a good idea. Paul. From rdieter at math.unl.edu Fri Jul 1 12:39:27 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 01 Jul 2005 07:39:27 -0500 Subject: Request for review: koffice In-Reply-To: <42C51F9D.5020503@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <42C51F9D.5020503@lowlatency.de> Message-ID: Andreas Bierfert wrote: > Rex Dieter wrote: >>For the love of all that is holy, please package the langpack files >>separately (altogether or separate src.rpm's I don't care, just as long >>as they are .noarch.rpm's), and follow upstream naming. > Befor I do that... > - - build of language stuff ties in with koffice nicely And what if a patch is released for a single koffice-l10 tarball/language? You'll to rebuild *the whole friggin thing*. Besides, the koffice lang packages *really* should be noarch (and could possibly be shared among all distro/releases/archs). > - - ooo langpack files are within the main package as well AFAICT, no they aren't. ??? > - - naming is exactly like ooo naming which IMHO is better for fedora users ooo doesn't have separate, upstream language packs. Apples/Oranges. -- Rex From bugs.michael at gmx.net Fri Jul 1 12:42:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 14:42:56 +0200 Subject: Request for review: libpqxx In-Reply-To: <42C51E00.2010300@lowlatency.de> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> <42C51E00.2010300@lowlatency.de> Message-ID: <20050701144256.55137f01.bugs.michael@gmx.net> On Fri, 01 Jul 2005 12:42:08 +0200, Andreas Bierfert wrote: > > As a rule of thumb: whenever a -devel package contains a foo-config > > executable or a pkg-config file, these are worth examining for dependencies > > on other -devel packages. If no foo-config program or pkg-config file > > is included, it may need more effort to examine included C/C++ headers > > for dependencies. > > Is this a policy? I hope so. And if it isn't a policy already, it ought to become one. The rationale is this, roughly: If you, as a software developer, want to use the libfoo API, you install libfoo-devel. That should be enough. You should not need to go through the tiresome process of noticing that headers from libfoo-devel include headers from libbar-devel, and headers from libbar-devel need libbaz-devel, and so on. Maybe the next version of libfoo accesses another library's headers, although you still use only libfoo directly. If there is a foo-config helper script, which returns compiler/linker options which are needed for building with libfoo, it should work out-of-the-box and not fail, because something's required but missing. Similarly, if you use pkg-config for your project, you want that checks like "pkg-config --exists libfoo" return true if libfoo is available. However, pkg-config files have dependencies (they are called "Requires:", too, inside the files, btw) on other pkg-config files and hence on other packages. And pkg-config fails if such dependencies are broken, and e.g. the linker options returned by "pkg-config --libs libfoo" would fail because of missing libraries, or "pkg-config --cflags libfoo" would return several compiler options for locations in where to search for needed headers from library dependencies. As a packager, you see your package, which had been working fine for a long time due to complete build requirements, break badly all of a sudden, because of a broken pkg-config dependency chain somewhere. Bug #161688 as an example. Assumedly all GTK+ v2 packages broke due to incomplete dependencies in "cairo-devel", although hardly any of the packages need cairo-devel directly. > I don't know... I reather would think if somebody needs to use > the devel package that somebody would need to install the libs to and not do it > automatically via Requires. That is why they where missing in the first place in > my spec... I don't care one way or the other myself both is perfectly ok... it's > just a question of consistancy between all packages... :) Either there is a dependency or there is none. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.00 1.07 1.07 From tcallawa at redhat.com Fri Jul 1 12:42:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 07:42:41 -0500 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C52083.5060303@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> <42C51B82.9020609@city-fan.org> <1120215034.3741.165.camel@mccallum.corsepiu.local> <42C52083.5060303@city-fan.org> Message-ID: <1120221761.8990.103.camel@localhost.localdomain> On Fri, 2005-07-01 at 11:52 +0100, Paul Howarth wrote: > Neither do I; I was just seeking other opinions, because it conflicts > with a MUST in the package review checklist and lots of existing > packages have this issue. The whole point of the license include MUST is two-fold: 1. To remove any and all confusion as to which license(s) the package is under 2. To be extra sure we're conforming to those licenses that requires the license text to be included (and or prominently displayed). Take ten seconds, dump the perl license into a text file, and include it as a Source1. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From paul at city-fan.org Fri Jul 1 12:45:46 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 13:45:46 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <1120221761.8990.103.camel@localhost.localdomain> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> <42C51B82.9020609@city-fan.org> <1120215034.3741.165.camel@mccallum.corsepiu.local> <42C52083.5060303@city-fan.org> <1120221761.8990.103.camel@localhost.localdomain> Message-ID: <42C53AFA.1090705@city-fan.org> Tom 'spot' Callaway wrote: > On Fri, 2005-07-01 at 11:52 +0100, Paul Howarth wrote: > > >>Neither do I; I was just seeking other opinions, because it conflicts >>with a MUST in the package review checklist and lots of existing >>packages have this issue. > > > The whole point of the license include MUST is two-fold: > > 1. To remove any and all confusion as to which license(s) the package is > under > > 2. To be extra sure we're conforming to those licenses that requires the > license text to be included (and or prominently displayed). > > Take ten seconds, dump the perl license into a text file, and include it > as a Source1. :) Is anyone going to go through all the other perl modules in Extras, and for that matter Core (many of which have the same issue) and do the same there? Paul. From rc040203 at freenet.de Fri Jul 1 12:48:04 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:48:04 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <1120221761.8990.103.camel@localhost.localdomain> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> <42C51B82.9020609@city-fan.org> <1120215034.3741.165.camel@mccallum.corsepiu.local> <42C52083.5060303@city-fan.org> <1120221761.8990.103.camel@localhost.localdomain> Message-ID: <1120222085.3741.205.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 07:42 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-01 at 11:52 +0100, Paul Howarth wrote: > > > Neither do I; I was just seeking other opinions, because it conflicts > > with a MUST in the package review checklist and lots of existing > > packages have this issue. > > The whole point of the license include MUST is two-fold: > > 1. To remove any and all confusion as to which license(s) the package is > under > > 2. To be extra sure we're conforming to those licenses that requires the > license text to be included (and or prominently displayed). > > Take ten seconds, dump the perl license into a text file, and include it > as a Source1. :) C'mon, that's more papal than the pope #:( ) Ralf From rc040203 at freenet.de Fri Jul 1 12:48:20 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:48:20 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C5397A.9010005@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> Message-ID: <1120222100.3741.207.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 13:39 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: > > > > > >>- I'd put %check after %install rather than after %clean, so that builds > >>on rpm versions not supporting %check could still work. > > > > > > Does order of spec sections matter? (I don't think so) > > Current rpm versions run the %check scriptlet after %install, if %check > is present. > > Older rpm versions don't understand %check, and will barf when they come > across it. How old is old here? "Old rpms" also didn't have "perl_archlib" and "perl_vendorlib", while rpm since FC3 has them. Also this FE, which currently takes care about FC3, FC4 and FC5, so anything older isn't of real importance. Ralf From bugs.michael at gmx.net Fri Jul 1 12:51:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 14:51:38 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C5397A.9010005@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> Message-ID: <20050701145138.7c5bea18.bugs.michael@gmx.net> On Fri, 01 Jul 2005 13:39:22 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: > > > > > >>- I'd put %check after %install rather than after %clean, so that builds > >>on rpm versions not supporting %check could still work. > > > > > > Does order of spec sections matter? (I don't think so) > > Current rpm versions run the %check scriptlet after %install, if %check > is present. Regardless of where I put %check inside the spec? I can move the %files section at the top of the spec. Could I do the same with %check or %clean? ;) > Older rpm versions don't understand %check, and will barf when they come > across it. That was not the questions. > If instead you have: > > %install > ... > %clean > ... > %check || : > ... > > then old versions of rpm How old? > will run the %check scriptlet at the end of the > %clean scriptlet, i.e. just after everything has been deleted. Not a > good idea. From rc040203 at freenet.de Fri Jul 1 12:55:35 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:55:35 +0200 Subject: Request for review: perl-Sort-Versions Message-ID: <1120222535.3741.210.camel@mccallum.corsepiu.local> [Reposting, because the first posting doesn't seems to have made it to the list.] Hi, Another perl module: perl-Sort-Versions. %description A perl 5 module for sorting of revision-like numbers Sort::Versions allows easy sorting of mixed non-numeric and numeric strings, like the 'version numbers' that many shared library systems and revision control packages use. This is quite useful if you are trying to deal with shared libraries. It can also be applied to applications that intersperse variable-width numeric fields within text. Other applications can undoubtedly be found. Files: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Sort-Versions.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Sort-Versions-1.5-1.src.rpm This package is a dependency of ExtUtils::AutoInstall, a pretty central and important module currently missing in Fedora. Review (and approval) appreciated, TIA Ralf From paul at city-fan.org Fri Jul 1 12:56:35 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 13:56:35 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <20050701145138.7c5bea18.bugs.michael@gmx.net> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> <20050701145138.7c5bea18.bugs.michael@gmx.net> Message-ID: <42C53D83.2070808@city-fan.org> Michael Schwendt wrote: > On Fri, 01 Jul 2005 13:39:22 +0100, Paul Howarth wrote: > >>Michael Schwendt wrote: >> >>>On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: >>> >>> >>> >>>>- I'd put %check after %install rather than after %clean, so that builds >>>>on rpm versions not supporting %check could still work. >>> >>> >>>Does order of spec sections matter? (I don't think so) >> >>Current rpm versions run the %check scriptlet after %install, if %check >>is present. > > > Regardless of where I put %check inside the spec? I can move the %files > section at the top of the spec. Could I do the same with %check or > %clean? ;) Try rearranging them and see. >>Older rpm versions don't understand %check, and will barf when they come >>across it. > > > That was not the questions. > > >>If instead you have: >> >>%install >>... >>%clean >>... >>%check || : >>... >> >>then old versions of rpm > > > How old? rpm 4.0.something I think. Well before the dawn of Fedora. So for a spec file tailored for Extras, none of this matters. However, it's perfectly possible to write spec files that will build just fine on really old Red Hat Linuxes, and still meet Extras packaging guidelines. Obviously most people won't want to bother with that, and that's OK, but if they're not bothered about backwards compatibility, there's no need for the "|| :" after %check - and that's all my original comment was about in the review. Paul. From rc040203 at freenet.de Fri Jul 1 12:56:42 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:56:42 +0200 Subject: Request for review: perl-Text-Glob Message-ID: <1120222603.3741.213.camel@mccallum.corsepiu.local> [Reposting, yet another posting having been lost] Hi, Another perl module: perl-Text-Glob. %description Text::Glob implements glob(3) style matching that can be used to match against text, rather than fetching names from a filesystem. If you want to do full file globbing use the File::Glob module instead. Files: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Text-Glob.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Text-Glob-0.06-1.src.rpm Review (and approval) appreciated, TIA Ralf From rc040203 at freenet.de Fri Jul 1 12:57:30 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:57:30 +0200 Subject: Request for review: perl-File-Find-Rule Message-ID: <1120222651.3741.216.camel@mccallum.corsepiu.local> [Reposted ...] Hi, And yet another perl module: perl-File-Find-Rule This perl-module BR's perl-Text-Glob and perl-Number-Compare, I had submitted earlier today. %description File::Find::Rule is a friendlier interface to File::Find. It allows you to build rules which specify the desired files and directories. Files: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-File-Find-Rule.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-File-Find-Rule-0.06-1.src.rpm Review (and approval) appreciated, TIA Ralf From rdieter at math.unl.edu Fri Jul 1 12:53:06 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 01 Jul 2005 07:53:06 -0500 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> <42C51F9D.5020503@lowlatency.de> Message-ID: Rex Dieter wrote: >> - - ooo langpack files are within the main package as well > > > AFAICT, no they aren't. ??? Sorry, I misread. Yes, you're correct, but ooo's langpackages can't easily be built outside of an ooo-build either... koffice's can (actually, they were designed to be built separatately). -- Rex From rc040203 at freenet.de Fri Jul 1 12:59:34 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 14:59:34 +0200 Subject: Request for review: perl-Devel-StackTrace Message-ID: <1120222775.3741.218.camel@mccallum.corsepiu.local> [Reposted, ...] Hi, perl module: perl-Devel-StackTrace. %description The Devel::StackTrace module contains two classes, Devel::StackTrace and Devel::StackTraceFrame. The goal of this object is to encapsulate the information that can found through using the caller() function, as well as providing a simple interface to this data. The Devel::StackTrace object contains a set of Devel::StackTraceFrame objects, one for each level of the stack. The frames contain all the data available from caller() as of Perl 5.6.0. Files: ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Devel-StackTrace.spec ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Devel-StackTrace-1.11-1.src.rpm Review (and approval) appreciated, TIA Ralf From tcallawa at redhat.com Fri Jul 1 13:01:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:01:41 -0500 Subject: Request for review: libpqxx In-Reply-To: <42C51E00.2010300@lowlatency.de> References: <42C27813.3030405@lowlatency.de> <42C39F6C.9040607@lowlatency.de> <1120172641.8990.76.camel@localhost.localdomain> <20050701023007.41a1c3c7.bugs.michael@gmx.net> <42C51E00.2010300@lowlatency.de> Message-ID: <1120222901.8990.114.camel@localhost.localdomain> On Fri, 2005-07-01 at 12:42 +0200, Andreas Bierfert wrote: > So is this ok for import/approval? Approved. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 1 13:03:36 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:03:36 -0500 Subject: Request for review: wv2 In-Reply-To: <42C51EC2.1020100@lowlatency.de> References: <42C27815.9080304@lowlatency.de> <42C31007.2020505@lowlatency.de> <42C3896D.9020708@lowlatency.de> <1120171962.8990.67.camel@localhost.localdomain> <42C51EC2.1020100@lowlatency.de> Message-ID: <1120223016.8990.118.camel@localhost.localdomain> On Fri, 2005-07-01 at 12:45 +0200, Andreas Bierfert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom 'spot' Callaway wrote: > > The blockers are easy to resolve. If you fix them, I'll approve the > > fixed spec file. > > done... maybe just let me mention the comment issue: My name in general is very > long (at least in combination with the email addy). Thus I think the 80 chars > per line limit is more important then having the version information on the same > line. This has been an issue before and up till now (see my other packages) been > ok with everybody... I changed it for wv2 an libpqxx because they stay unter 80 > chars in a line (79). > > http://fedora.lowlatency.de/review/wv2-0.2.2-4.src.rpm > http://fedora.lowlatency.de/review/wv2.spec > > Hope this is good for import/approval now. Ahh, OK. I see. That explanation works for me, I won't complain about that anymore. :) APPROVED. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From oliver at linux-kernel.at Fri Jul 1 13:10:16 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 15:10:16 +0200 Subject: CVS Sponsor needed for Axel Liljencrantz Message-ID: <42C540B8.2060808@linux-kernel.at> Hi! I noticed, that Axel has no CVS sponsor yet. And because I don't have the right to CVS sponsor him, I write a mail to the list, so maybe someone stands up and does it... Thanks a lot for - at least - reading this mail. :-) Best, Oliver From tcallawa at redhat.com Fri Jul 1 13:14:46 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:14:46 -0500 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> Message-ID: <1120223686.8990.125.camel@localhost.localdomain> On Thu, 2005-06-30 at 22:24 -0500, Rex Dieter wrote: > Andreas Bierfert wrote: > > > koffice-1.4.0a: > > KOffice - Integrated Office Suite > > KOffice is a free, integrated office suite for KDE, the K Desktop Environment. > > > http://fedora.lowlatency.de/review/koffice.spec > > http://fedora.lowlatency.de/review/koffice-1.4.0a-1.src.rpm > > For the love of all that is holy, please package the langpack files > separately (altogether or separate src.rpm's I don't care, just as long > as they are .noarch.rpm's), and follow upstream naming. I agree with this. Please make all of those langpack files into separate noarch packages (and use %find_lang if possible). I'm willing to review them all at once, when they're done. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 1 13:16:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:16:56 -0500 Subject: Request for review: perl-Number-Compare In-Reply-To: <1120222085.3741.205.camel@mccallum.corsepiu.local> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <1120213268.3741.159.camel@mccallum.corsepiu.local> <42C51B82.9020609@city-fan.org> <1120215034.3741.165.camel@mccallum.corsepiu.local> <42C52083.5060303@city-fan.org> <1120221761.8990.103.camel@localhost.localdomain> <1120222085.3741.205.camel@mccallum.corsepiu.local> Message-ID: <1120223816.8990.129.camel@localhost.localdomain> On Fri, 2005-07-01 at 14:48 +0200, Ralf Corsepius wrote: > On Fri, 2005-07-01 at 07:42 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2005-07-01 at 11:52 +0100, Paul Howarth wrote: > > > > > Neither do I; I was just seeking other opinions, because it conflicts > > > with a MUST in the package review checklist and lots of existing > > > packages have this issue. > > > > The whole point of the license include MUST is two-fold: > > > > 1. To remove any and all confusion as to which license(s) the package is > > under > > > > 2. To be extra sure we're conforming to those licenses that requires the > > license text to be included (and or prominently displayed). > > > > Take ten seconds, dump the perl license into a text file, and include it > > as a Source1. :) > C'mon, that's more papal than the pope #:( ) *waves his holy packaging stick around* C'mon. It will take you 10 seconds, then you can use it for every genericly licensed perl package you ever build. It's not like I asked you to memorize all seven parts of "The Rime of the Ancient Mariner" in Latin. ;) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From oliver at linux-kernel.at Fri Jul 1 13:17:09 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 15:17:09 +0200 Subject: Request for review: perl-Want In-Reply-To: <42C5237A.6070306@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> <42C5237A.6070306@linux-kernel.at> Message-ID: <42C54255.9000304@linux-kernel.at> On 07/01/2005 01:05 PM, Oliver Falk wrote: > On 07/01/2005 01:00 PM, Ralf Corsepius wrote: > >> On Fri, 2005-07-01 at 12:36 +0200, Oliver Falk wrote: >> >>> On 07/01/2005 11:45 AM, Ralf Corsepius wrote: >>> >>>> On Fri, 2005-07-01 at 11:26 +0200, Oliver Falk wrote: >> >> >>>> This would be a bit more general than what I use, but doesn't have any >>>> impact on this package's behavior. >>> >>> >>> It's just because the perl spec template does it this way, so I >>> recommend it as well! >> >> Let me put it this way: To me, all that matters is function. >> >> So, I am not going to adopt a template for stylish reasons, when I have >> something that "appears to work" for years. >> >> If others feel "slavishly hanging on to templates is a good thing", I am >> giving them "card blanche" to modify my perl-rpm-specs after cvs check >> in. > > It's your decision. :-) * Builds fine * Installs fine * Uninstalls fine * rpmlint is quiet * %dist macro is allready in place From my point of view, it looks ok, apart from the not consistent identations :-) Best, Oliver From tcallawa at redhat.com Fri Jul 1 13:18:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:18:25 -0500 Subject: CVS Sponsor needed for Axel Liljencrantz In-Reply-To: <42C540B8.2060808@linux-kernel.at> References: <42C540B8.2060808@linux-kernel.at> Message-ID: <1120223905.8990.131.camel@localhost.localdomain> On Fri, 2005-07-01 at 15:10 +0200, Oliver Falk wrote: > Hi! > > I noticed, that Axel has no CVS sponsor yet. And because I don't have > the right to CVS sponsor him, I write a mail to the list, so maybe > someone stands up and does it... He's not listed in the CVS accounts system as needing one. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From oliver at linux-kernel.at Fri Jul 1 13:19:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 15:19:57 +0200 Subject: CVS Sponsor needed for Axel Liljencrantz In-Reply-To: <1120223905.8990.131.camel@localhost.localdomain> References: <42C540B8.2060808@linux-kernel.at> <1120223905.8990.131.camel@localhost.localdomain> Message-ID: <42C542FD.9090700@linux-kernel.at> On 07/01/2005 03:18 PM, Tom 'spot' Callaway wrote: > On Fri, 2005-07-01 at 15:10 +0200, Oliver Falk wrote: > >>Hi! >> >>I noticed, that Axel has no CVS sponsor yet. And because I don't have >>the right to CVS sponsor him, I write a mail to the list, so maybe >>someone stands up and does it... > > He's not listed in the CVS accounts system as needing one. Axel, please request an account: https://admin.fedora.redhat.com/accounts/ Best, Oliver From oliver at linux-kernel.at Fri Jul 1 13:38:37 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 15:38:37 +0200 Subject: ATTENTION: ppc buildsys problem!? (WAS: Re: Build Result: rblcheck on 4) In-Reply-To: <20050701132929.AA861A1D7@extras64.linux.duke.edu> References: <20050701132929.AA861A1D7@extras64.linux.duke.edu> Message-ID: <42C5475D.5020608@linux-kernel.at> On 07/01/2005 03:29 PM, buildsys at fedoraproject.org wrote: > Build of rblcheck on 4 failed to complete on one or more archs. Please see logs at: > http://extras64.linux.duke.edu/failed/4/rblcheck ppc buildsys problem: Traceback (most recent call last): File "/usr/bin/mach", line 1991, in ? main (config, sys.argv[1:]) File "/usr/bin/mach", line 1964, in main output = Root.__dict__[command] (root, args[1:]) File "/usr/bin/mach", line 867, in rebuild self.setup (['build', ]) File "/usr/bin/mach", line 857, in setup Root.__dict__[method] (self) File "/usr/bin/mach", line 1326, in _setup_minimal self.config_recreate (filename) File "/usr/bin/mach", line 481, in config_recreate file = open (os.path.join (self.rootdir, tmpname), 'w') IOError: [Errno 2] No such file or directory: '/var/lib/mach/roots/fedora-4-ppc-core/tmp/hosts' Best, Oliver From tcallawa at redhat.com Fri Jul 1 13:40:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:40:19 -0500 Subject: Request for review: pygsl In-Reply-To: References: Message-ID: <1120225220.8990.152.camel@localhost.localdomain> On Fri, 2005-07-01 at 12:48 +0100, Jos? Matos wrote: > Hi, > this is my first message here. I have been (GNU/)Linux exclusively for the > last 9 years, after Slackware I have changed to Red Hat Linux 5.0 and from > there I have updated the system to the latest Fedora. :-) > > I'm doing a PhD on econophysics (applying techniques from statistical > physical to the study of financial time series) and I have contributed > before to several free software projects, being the most import LyX where I > am one of the core developers. > > Due to my work I have been interested and I have packaged for local > consuption several scientific packages related with python and R. > > I have done all the process to become an FE packager. And I just sponsored you. > As a first step I propose for inclusion in FE pygsl. > > http://www.fc.up.pt/pessoas/jamatos/pygsl.spec > http://www.fc.up.pt/pessoas/jamatos/pygsl-0.3.2-1.src.rpm > > Possible problem for this package: > > -Name: It already has py in its name is it necessary to change it to > python-pygsl? Nope. pygsl is fine, since it has py in its name. > -License: Although the project is GPL (it is clearly placed in the > sources) there isn't no license in the source package. Find a copy of the GPL and put it in as Source1. > -FC3: This version of pygsl does not compile in FC3 since it links to > wavelets that are only present in gsl 1.6. Also the previous version 0.3.1 > doesn't compile in FC4. Then you won't need an FC-3 branch for this package. :) > I have compile this using mock in i386 and x86_64 architecture without > problems, the only complain of rpmlint is that: > > - there is no binary > - several example files are not non executable scripts > > I think that these are harmless... Yeah, I think so too. Review of pygsl: rpmlint checks: No output Bad: - Prefix: %{_prefix} makes this package relocatable. If you really want to do this, you have to make a good case in the request for review (see the MUST on relocatable packages in http://fedoraproject.org/wiki/PackageReviewGuidelines). You're probably better off just removing this line. - Vendor and Packager fields are set, they should be removed. - Source0 is not presented as the URL for the upstream source. This is important because reviewers need to check that the source in your SRPM matches the upstream source. Replace your existing Source0 line with: Source0: http://dl.sourceforge.net/%{name}/%{name}-%{version}.tar.gz - /usr/lib/python2.4/site-packages/pygsl is not owned by the package, when it should be (again, this is a byproduct of using a filelist for python packages, it will not mark directories, only files) Adding this line to the %files entry should do the trick: %dir %{python_sitearch}/pysql You also need to add this line to the top of your spec (to safely use %{python_sitearch}: %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} - You need to include a copy of the License (GPL) in the package. You can do this by downloading gpl.txt from: http://www.fsf.org/licensing/licenses/gpl.txt Then, you can add: Source1: gpl.txt In %build: cp %{SOURCE1} . And in %doc, add gpl.txt to the end of the existing line. (NOTE: You really want to push upstream to include the license text for you, because without it, they're technically in violation of the GPL) Good: - Package is named according to PackageNamingGuidelines - spec file name matches %{name} - License (GPL) OK, matches source license (but license is missing) - Spec file is in Am. English, is legible - Sources match upstream - Package compiles and builds on x86 (FC4) - No extra BuildRequires used - All other build deps in BuildRequires - No locales in spec files - No need for -devel or -docs subpackages - Permissions set correctly on files - %clean section exists - macro usage is consistent - package is code, not content - nothing in %doc affects runtime - no static libraries You've got some work ahead of you, but it is your first package. Fix those blocker items and I'll take another look at it. Remember that http://fedoraproject.org/wiki/PackageNamingGuidelines, http://fedoraproject.org/wiki/PackageReviewGuidelines and http://www.fedoraproject.org/wiki/PackagingGuidelines are your friends. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From oliver at linux-kernel.at Fri Jul 1 13:41:00 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 15:41:00 +0200 Subject: APPROVED: perl-Want Message-ID: <42C547EC.9020601@linux-kernel.at> Name: perl-Want Summary: Perl module implementing a generalisation of wantarray This module generalises the mechanism of the wantarray function, allowing a function to determine in some detail how its return value is going to be immediately used. Maintainer: Ralf Corsepius Reviewer: Oliver Falk From bugs.michael at gmx.net Fri Jul 1 13:46:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 15:46:15 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C53D83.2070808@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> <20050701145138.7c5bea18.bugs.michael@gmx.net> <42C53D83.2070808@city-fan.org> Message-ID: <20050701154615.55899b9f.bugs.michael@gmx.net> On Fri, 01 Jul 2005 13:56:35 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > On Fri, 01 Jul 2005 13:39:22 +0100, Paul Howarth wrote: > > > >>Michael Schwendt wrote: > >> > >>>On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: > >>> > >>> > >>> > >>>>- I'd put %check after %install rather than after %clean, so that builds > >>>>on rpm versions not supporting %check could still work. > >>> > >>> > >>>Does order of spec sections matter? (I don't think so) > >> > >>Current rpm versions run the %check scriptlet after %install, if %check > >>is present. > > > > > > Regardless of where I put %check inside the spec? I can move the %files > > section at the top of the spec. Could I do the same with %check or > > %clean? ;) > > Try rearranging them and see. > > >>Older rpm versions don't understand %check, and will barf when they come > >>across it. > > > > > > That was not the questions. > > > > > >>If instead you have: > >> > >>%install > >>... > >>%clean > >>... > >>%check || : > >>... > >> > >>then old versions of rpm > > > > > > How old? > > rpm 4.0.something I think. Well before the dawn of Fedora. So for a spec > file tailored for Extras, none of this matters. However, it's perfectly > possible to write spec files that will build just fine on really old Red > Hat Linuxes, and still meet Extras packaging guidelines. Obviously most > people won't want to bother with that, and that's OK, but if they're not > bothered about backwards compatibility, there's no need for the "|| :" > after %check - and that's all my original comment was about in the review. No, actually (as can be seen in the quote at the very top of this mail) you suggested reordering %install and %check. Here: > - I'd put %check after %install rather than after %clean, so that builds > on rpm versions not supporting %check could still work. I've never before payed attention to this. Hence my interest in the rationale for such a recommendation. And I'm still confused. Does it matter where to put the %check section in a spec? [I'm aware of "%check || :" from fedora.us times and multi-dist src.rpms, that are supposed to build on RHL 7.3, too, e.g.] From tcallawa at redhat.com Fri Jul 1 13:54:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 08:54:06 -0500 Subject: Reviews still needed Message-ID: <1120226047.8990.162.camel@localhost.localdomain> Hi guys, I would greatly appreciate it if some of you could help review some of my pending packages: gambas (x86 only): https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00454.html ebtables: https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00704.html xbase: https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00732.html xbsql: https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00732.html rekall: https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00732.html I would greatly appreciate it. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Fri Jul 1 13:57:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 15:57:57 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <20050701154615.55899b9f.bugs.michael@gmx.net> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> <20050701145138.7c5bea18.bugs.michael@gmx.net> <42C53D83.2070808@city-fan.org> <20050701154615.55899b9f.bugs.michael@gmx.net> Message-ID: <20050701155757.7a98a65a.bugs.michael@gmx.net> On Fri, 1 Jul 2005 15:46:15 +0200, Michael Schwendt wrote: -snip- Ah, I think I understand what you tried to point out. The code in %check would be appended to the previous spec section, when an old rpmbuild doesn't see %check as a separate spec section, but as just an ordinary undefined macro. Okay. Then it makes sense to put it after %install and not after %clean. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 3.25 2.57 1.67 From paul at city-fan.org Fri Jul 1 13:57:31 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 14:57:31 +0100 Subject: Request for review: perl-Number-Compare In-Reply-To: <20050701154615.55899b9f.bugs.michael@gmx.net> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> <20050701145138.7c5bea18.bugs.michael@gmx.net> <42C53D83.2070808@city-fan.org> <20050701154615.55899b9f.bugs.michael@gmx.net> Message-ID: <42C54BCB.1000708@city-fan.org> Michael Schwendt wrote: > On Fri, 01 Jul 2005 13:56:35 +0100, Paul Howarth wrote: > > >>Michael Schwendt wrote: >> >>>On Fri, 01 Jul 2005 13:39:22 +0100, Paul Howarth wrote: >>> >>> >>>>Michael Schwendt wrote: >>>> >>>> >>>>>On Fri, 01 Jul 2005 10:32:00 +0100, Paul Howarth wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>- I'd put %check after %install rather than after %clean, so that builds >>>>>>on rpm versions not supporting %check could still work. >>>>> >>>>> >>>>>Does order of spec sections matter? (I don't think so) >>>> >>>>Current rpm versions run the %check scriptlet after %install, if %check >>>>is present. >>> >>> >>>Regardless of where I put %check inside the spec? I can move the %files >>>section at the top of the spec. Could I do the same with %check or >>>%clean? ;) >> >>Try rearranging them and see. >> >> >>>>Older rpm versions don't understand %check, and will barf when they come >>>>across it. >>> >>> >>>That was not the questions. >>> >>> >>> >>>>If instead you have: >>>> >>>>%install >>>>... >>>>%clean >>>>... >>>>%check || : >>>>... >>>> >>>>then old versions of rpm >>> >>> >>>How old? >> >>rpm 4.0.something I think. Well before the dawn of Fedora. So for a spec >>file tailored for Extras, none of this matters. However, it's perfectly >>possible to write spec files that will build just fine on really old Red >>Hat Linuxes, and still meet Extras packaging guidelines. Obviously most >>people won't want to bother with that, and that's OK, but if they're not >>bothered about backwards compatibility, there's no need for the "|| :" >>after %check - and that's all my original comment was about in the review. > > > No, actually (as can be seen in the quote at the very top of this mail) > you suggested reordering %install and %check. Here: > > >>- I'd put %check after %install rather than after %clean, so that builds >>on rpm versions not supporting %check could still work. > > > I've never before payed attention to this. Hence my interest in > the rationale for such a recommendation. And I'm still confused. Does > it matter where to put the %check section in a spec? > > [I'm aware of "%check || :" from fedora.us times and multi-dist src.rpms, > that are supposed to build on RHL 7.3, too, e.g.] Let's try again: If you want backwards compatbility, you need to use "%check || :" and the %check section must go after %install because on old distros, %check is not recognised as being the start of a new script. The result is that everything in %check gets run as part of the %install script on those systems. If you don't want backwards compatbility, you can put %check and %install and %clean in any order you like and you don't need the "|| :" on the %check line. Paul. From rdieter at math.unl.edu Fri Jul 1 13:57:11 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 01 Jul 2005 08:57:11 -0500 Subject: Request for review: koffice In-Reply-To: <42C46C17.3050805@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> Message-ID: Andreas Bierfert wrote: > http://fedora.lowlatency.de/review/koffice.spec > http://fedora.lowlatency.de/review/koffice-1.4.0a-1.src.rpm 0. Epoch: Just and FYI... previous koffice pkgs had Epoch: 4 but since you're splitting things up, you can probably get away with omitting this legacy crud (see 1. Obsoletes below) 1. Please use versioned Obsoletes: -Obsoletes: koffice +Obsoletes: koffice <= 4:%{version}-%{release} And (mispelled/typo) -Obsoletes: koffice-k18n +Obsoletes: koffice-i18n < 4:%{version} IMO, should be moved to the langpacks(??), but I wouldn't technically say it's wrong to include it in -core either (since it still works, and is much simpler since it avoids many duplicated Obsoletes in each langpack). 2. Use %lang(_locale_) in %files section for all %{_datadir}/locale/_locale_/LC_MESSAGES/* %{_datadir}/doc/HTML/_locale_/* bits, e.g. %lang(de) %{_datadir}/locale/de/* %lang(de) %{_datadir}/doc/HTML/de/* 3. Extra BuildRequires. I'm pretty sure these are extraneous and can be omitted: (though it's not a huge deal, it's mostly harmless to include extra BR's): BuildRequires: kdebase-devel BuildRequires: qt-devel (Req'd by kdelibs-devel already) BuildRequires: glib2-devel (wv2-devel use this, it should pull it in) BuildRequires: libidn-devel # (can omit gamin-devel when http://bugzilla.redhat.com/159090 is fixed) BuildRequires: gamin-devel BuildRequires: libstdc++-devel # audio libs? BuildRequires: alsa-lib-devel BuildRequires: libvorbis-devel BuildRequires: libogg-devel BuildRequires: arts-devel (Req'd by kdelibs-devel) BuildRequires: esound-devel -- Rex From bugs.michael at gmx.net Fri Jul 1 14:04:24 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 16:04:24 +0200 Subject: Request for review: pygsl In-Reply-To: References: Message-ID: <20050701160424.1b70f7e9.bugs.michael@gmx.net> On Fri, 01 Jul 2005 12:48:25 +0100, Jos? Matos wrote: > http://www.fc.up.pt/pessoas/jamatos/pygsl.spec > http://www.fc.up.pt/pessoas/jamatos/pygsl-0.3.2-1.src.rpm Hmm, may I add that it is preferred form during reviewing to bump release with every package revision? I just arrived at Tom's review, clicked on above link and found a spec file which doesn't match the reviewed items. E.g. Tom points out that the pygsl directory is not included in the package. Contrary to that, in the spec I see that the directory is included, but no files at all: %files %defattr(-,root,root) %doc ChangeLog README CREDITS doc/ examples/ %dir %{python_sitelib}/pygsl Should be: %files %defattr(-,root,root) %doc ChangeLog README CREDITS doc/ examples/ %{python_sitelib}/pygsl/ [...] Without intentions to review this, I noticed: %install python setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT Should be: %install rm -rf $RPM_BUILD_ROOT python setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.06 1.34 1.41 From tcallawa at redhat.com Fri Jul 1 14:08:59 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 09:08:59 -0500 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> Message-ID: <1120226939.8990.166.camel@localhost.localdomain> On Fri, 2005-07-01 at 08:57 -0500, Rex Dieter wrote: > 2. Use %lang(_locale_) in %files section for all > %{_datadir}/locale/_locale_/LC_MESSAGES/* > %{_datadir}/doc/HTML/_locale_/* > bits, e.g. > %lang(de) %{_datadir}/locale/de/* > %lang(de) %{_datadir}/doc/HTML/de/* Better yet, split out the langpacks that are in separate source files and use %find_lang to scoop up the locales. (I don't think it will catch the HTML docs, so you should still do as Rex suggests for those files). ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Fri Jul 1 14:10:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 16:10:35 +0200 Subject: rpms/fish/devel fish.spec,1.1,1.2 In-Reply-To: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> References: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> Message-ID: <20050701161035.621cf1fe.bugs.michael@gmx.net> On Fri, 1 Jul 2005 07:08:36 -0400, Oliver Falk wrote: > Author: oliver > > Update of /cvs/extras/rpms/fish/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10684 > > Modified Files: > fish.spec > Log Message: > > - Added dist macro to the release > - Small spec beautifying Did you ask the packager for permission? We should not mandate spec formatting. Not only does it make cvs diffs really unreadable, formatting changes tend to come back as soon as the primary packager applies the next changes. This is really something that ought to stop. Reviews should focus on "must fix" issues. Tabs vs. spaces is not anything that improves package quality. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.00 1.18 1.33 From tcallawa at redhat.com Fri Jul 1 14:11:12 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 09:11:12 -0500 Subject: Request for review: pygsl In-Reply-To: <20050701160424.1b70f7e9.bugs.michael@gmx.net> References: <20050701160424.1b70f7e9.bugs.michael@gmx.net> Message-ID: <1120227072.8990.169.camel@localhost.localdomain> On Fri, 2005-07-01 at 16:04 +0200, Michael Schwendt wrote: > %files > %defattr(-,root,root) > %doc ChangeLog README CREDITS doc/ examples/ > %dir %{python_sitelib}/pygsl It used to say: %files -f INSTALLED_FILES %defattr(-,root,root) %doc ChangeLog README CREDITS doc/ examples/ > Should be: > > %install > rm -rf $RPM_BUILD_ROOT > python setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT Yes, this is my bad, I missed that. Thanks for catching it. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Christian.Iseli at licr.org Fri Jul 1 14:19:42 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 01 Jul 2005 16:19:42 +0200 Subject: Reviews still needed In-Reply-To: Your message of "Fri, 01 Jul 2005 08:54:06 CDT." <1120226047.8990.162.camel@localhost.localdomain> Message-ID: <200507011419.j61EJgfd021141@ludwig-alpha.unil.ch> Hi Spot, tcallawa at redhat.com said: > gambas (x86 only): https://www.redhat.com/archives/fedora-extras-list/ > 2005-June/msg00454.html Erm, in https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00535.html you stated: > Gambas is not endian clean, nor is it 64 bit clean. Until such time that > the upstream maintainer decides to resolve these issues somewhat, I'm > withdrawing my request for review. Did you change your mind ? Christian From rc040203 at freenet.de Fri Jul 1 14:20:08 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 16:20:08 +0200 Subject: Request for review: perl-Number-Compare In-Reply-To: <42C54BCB.1000708@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> <20050701145138.7c5bea18.bugs.michael@gmx.net> <42C53D83.2070808@city-fan.org> <20050701154615.55899b9f.bugs.michael@gmx.net> <42C54BCB.1000708@city-fan.org> Message-ID: <1120227608.3741.233.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 14:57 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > On Fri, 01 Jul 2005 13:56:35 +0100, Paul Howarth wrote: > > If you don't want backwards compatbility, you can put %check and > %install and %clean in any order you like and you don't need the "|| :" > on the %check line. The latter is what I am going to use in future, striving for RH-7.3/rpm-4.0 or rpm-3.x compatibility doesn't seem reasonable to me. These ancient rpm-versions are sufficiently incompatible to current versions of rpm that trying to strive for compatibility will fail at other places (Eg. in some of these rpm versions, %configure / % makeinstall had been broken, in others, conditionals (%if etc.) weren't functional etc. etc.). Ralf From oliver at linux-kernel.at Fri Jul 1 14:21:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 16:21:57 +0200 Subject: rpms/fish/devel fish.spec,1.1,1.2 In-Reply-To: <20050701161035.621cf1fe.bugs.michael@gmx.net> References: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> <20050701161035.621cf1fe.bugs.michael@gmx.net> Message-ID: <42C55185.90100@linux-kernel.at> On 07/01/2005 04:10 PM, Michael Schwendt wrote: > On Fri, 1 Jul 2005 07:08:36 -0400, Oliver Falk wrote: >>Author: oliver >> >>Update of /cvs/extras/rpms/fish/devel >>In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10684 >> >>Modified Files: >> fish.spec >>Log Message: >> >>- Added dist macro to the release >>- Small spec beautifying > > > Did you ask the packager for permission? > > We should not mandate spec formatting. Not only does it make cvs diffs > really unreadable, formatting changes tend to come back as soon as the > primary packager applies the next changes. > > This is really something that ought to stop. Reviews should focus > on "must fix" issues. Tabs vs. spaces is not anything that improves > package quality. No, I didn't ask Axel, I imported it for him and rechecked if everything is OK (and found the missing dist macro) and as I was checking I believed it's much better readable if I add a few tabs. That doesn't change functionality, but makes it easier for me to have an eye on the package that I did approve... Be sure, that I will check the package in future from time to time, just to be sure package quality is OK. :-) And you are correct, it doesn't improve package quality, but specfile readability. :-) Best, Oliver From rdieter at math.unl.edu Fri Jul 1 14:30:22 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 01 Jul 2005 09:30:22 -0500 Subject: Request for review: koffice In-Reply-To: <1120226939.8990.166.camel@localhost.localdomain> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: > On Fri, 2005-07-01 at 08:57 -0500, Rex Dieter wrote: > > >>2. Use %lang(_locale_) in %files section for all >>%{_datadir}/locale/_locale_/LC_MESSAGES/* >>%{_datadir}/doc/HTML/_locale_/* >>bits, e.g. >>%lang(de) %{_datadir}/locale/de/* >>%lang(de) %{_datadir}/doc/HTML/de/* > > > Better yet, split out the langpacks that are in separate source files > and use %find_lang to scoop up the locales. (I don't think it will catch > the HTML docs, so you should still do as Rex suggests for those files). If packaging them separately, here's a little scriptlet code I use at the end of %install for a lot kde packages to catch both locale and HTML doc bits: ## File lists # locale's %find_lang %{name} || touch %{name}.lang # HTML HTML_DIR=$(kde-config --expandvars --install html) if [ -d $RPM_BUILD_ROOT$HTML_DIR ]; then for lang_dir in $RPM_BUILD_ROOT$HTML_DIR/* ; do lang=$(basename $lang_dir) echo "%lang($lang) %doc $HTML_DIR/$lang/*" >> %{name}.lang done fi Then %files -f %{name}.lang and you're done. -- Rex From tcallawa at redhat.com Fri Jul 1 14:42:52 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 09:42:52 -0500 Subject: Reviews still needed In-Reply-To: <200507011419.j61EJgfd021141@ludwig-alpha.unil.ch> References: <200507011419.j61EJgfd021141@ludwig-alpha.unil.ch> Message-ID: <1120228972.8990.172.camel@localhost.localdomain> On Fri, 2005-07-01 at 16:19 +0200, Christian.Iseli at licr.org wrote: > Hi Spot, > > tcallawa at redhat.com said: > > gambas (x86 only): https://www.redhat.com/archives/fedora-extras-list/ > > 2005-June/msg00454.html > > Erm, in > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00535.html > you stated: > > Gambas is not endian clean, nor is it 64 bit clean. Until such time that > > the upstream maintainer decides to resolve these issues somewhat, I'm > > withdrawing my request for review. > > Did you change your mind ? Policy changed at FUDCon II. Basically, it is now ok for packages to not build on some architectures, as long as its documented that they do not. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From kaboom at oobleck.net Fri Jul 1 14:54:47 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 1 Jul 2005 10:54:47 -0400 (EDT) Subject: request for review: dirvish and required perl modules In-Reply-To: <1119898957.4656.68.camel@localhost.localdomain> References: <1119898957.4656.68.camel@localhost.localdomain> Message-ID: On Mon, 27 Jun 2005, Ville Skytta wrote: > On Mon, 2005-06-27 at 13:34 -0400, Chris Ricker wrote: > > > > > Approved with the attached patch applied: > - License is not Public Domain, except for some bits of Time::Timezone; > Distributable is AFAICS the best we can state here. > - Cosmetic: stuff not needed for noarch packages pruned, README added. > > Feel free to commit and I'll recheck and follow up with the approval > message. Thanks, all changes applied and imported into devel later, chris From ville.skytta at iki.fi Fri Jul 1 14:59:55 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 17:59:55 +0300 Subject: rpms/fish/devel fish.spec,1.1,1.2 In-Reply-To: <42C55185.90100@linux-kernel.at> References: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> <20050701161035.621cf1fe.bugs.michael@gmx.net> <42C55185.90100@linux-kernel.at> Message-ID: <1120229995.2815.346.camel@localhost.localdomain> On Fri, 2005-07-01 at 16:21 +0200, Oliver Falk wrote: > And you are correct, it doesn't improve package quality, but specfile > readability. :-) That's subjective. Many people find the "indented" style more readable, while others exactly the opposite. As long as there's no policy, it is up to the package _maintainer_ to decide, and _all others_ to respect. From oliver at linux-kernel.at Fri Jul 1 15:04:44 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 17:04:44 +0200 Subject: ebtables (WAS: Re: Reviews still needed) In-Reply-To: <1120226047.8990.162.camel@localhost.localdomain> References: <1120226047.8990.162.camel@localhost.localdomain> Message-ID: <42C55B8C.2020101@linux-kernel.at> On 07/01/2005 03:54 PM, Tom 'spot' Callaway wrote: > ebtables: > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00704.html TODO * Don't include the INSTALL file in %doc section, as it is not of interesst for end-users and it contains wrong paths (eg /usr/local stuff). OK * Builds fine on FCdev i386 (don't know about x86_64) * Installs fine * Uninstalls fine * Starting via initscript works * License OK * Source matches upstream * install cleans out the build root * clean exists * No BuildRequires needed * No need for subpackages * Use of macros is consistant Call it an approval, if you kick out the INSTALL file. :-) Best, Oliver From adrian at lisas.de Fri Jul 1 15:14:04 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 1 Jul 2005 17:14:04 +0200 Subject: Request for Review: Rekall and dependencies In-Reply-To: <1119238318.11411.8.camel@localhost.localdomain> References: <1119238318.11411.8.camel@localhost.localdomain> Message-ID: <20050701151404.GA8953@lisas.de> On Sun, Jun 19, 2005 at 10:31:58PM -0500, Tom 'spot' Callaway wrote: > xbase: XBase compatible database library and tools > > XBase is an xbase (i.e. dBase, FoxPro, etc.) compatible C++ class > library originally by Gary Kunkel and others (see the AUTHORS file). > > XBase is useful for accessing data in legacy dBase 3 and 4 database > files as well as a general light-weight database engine. It includes > support for DBF (dBase version 3 and 4) data files, NDX and NTX indexes, > and DBT (dBase version 3 and 4). It supports file and record locking > under *nix OS's. > > SRPM: http://auroralinux.org/people/spot/review/xbase-2.0.0-1.src.rpm > SPEC: http://auroralinux.org/people/spot/review/xbase.spec rpmlint complains about: W: xbase invalid-license LGPL (binaries GPL) but I wouldn't see this as a blocker + source matches upstream + builds in mock + -devel subpackage with .a, .so, headers and documentation - builds not on my system because of missing BR: doxygen According to http://fedoraproject.org/buildgroups/4/i386/buildroots.xml doxygen is part of build and therefore it works in mock. But as it is not part of http://fedoraproject.org/wiki/PackagingGuidelines#head-5e0efda65c4d4266d60c269ced6ea1c28051cb6e I think it has to be added. Maybe only the html documentation or the latex should be part of the package and not both. Especially as the tex files are not compiled it probably makes more sense to only include the html docs. Adrian -- Adrian Reber http://lisas.de/~adrian/ A voice crackles in Calvin's radio: "Enemy fighters at two o'clock!" "Roger. What should I do until then?" From oliver at linux-kernel.at Fri Jul 1 15:15:11 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jul 2005 17:15:11 +0200 Subject: rpms/fish/devel fish.spec,1.1,1.2 In-Reply-To: <1120229995.2815.346.camel@localhost.localdomain> References: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> <20050701161035.621cf1fe.bugs.michael@gmx.net> <42C55185.90100@linux-kernel.at> <1120229995.2815.346.camel@localhost.localdomain> Message-ID: <42C55DFF.3020808@linux-kernel.at> On 07/01/2005 04:59 PM, Ville Skytt? wrote: > On Fri, 2005-07-01 at 16:21 +0200, Oliver Falk wrote: >>And you are correct, it doesn't improve package quality, but specfile >>readability. :-) > > That's subjective. Many people find the "indented" style more readable, > while others exactly the opposite. As long as there's no policy, it is > up to the package _maintainer_ to decide, and _all others_ to respect. My fault, ok? Could we stop discussing a few spaces and tabs, as they are whitespaces and whitespaces are 'nothing', so we are discussing 'nothing'. :-P Don't get me wrong, I read and understood what you wrote! But we really shouldn't discuss it too much... Best, Oliver From Christian.Iseli at licr.org Fri Jul 1 15:19:00 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 01 Jul 2005 17:19:00 +0200 Subject: Reviews still needed In-Reply-To: Your message of "Fri, 01 Jul 2005 09:42:52 CDT." <1120228972.8990.172.camel@localhost.localdomain> Message-ID: <200507011519.j61FJ09e021727@ludwig-alpha.unil.ch> tcallawa at redhat.com said: > Policy changed at FUDCon II. Basically, it is now ok for packages to not > build on some architectures, as long as its documented that they do not. Ok. In that case, the questions I asked in https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00488.html still stand (except for the compiler warnings, which can be ignored for x86 :-) I suppose that strange looking character after Visual Basic (some kind of small c with a vertical bar through the middle) is supposed to be a registered trademark thing, but somehow my encoding doesn't grok your encoding. My $LANG is set to en_US.UTF-8 Cheers, Christian From ville.skytta at iki.fi Fri Jul 1 15:20:39 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 18:20:39 +0300 Subject: Availability of %check (was: Re: Request for review: perl-Number-Compare) In-Reply-To: <42C53D83.2070808@city-fan.org> References: <1120203071.3741.98.camel@mccallum.corsepiu.local> <42C50D90.2000406@city-fan.org> <20050701140912.6d559b57.bugs.michael@gmx.net> <42C5397A.9010005@city-fan.org> <20050701145138.7c5bea18.bugs.michael@gmx.net> <42C53D83.2070808@city-fan.org> Message-ID: <1120231239.2815.359.camel@localhost.localdomain> On Fri, 2005-07-01 at 13:56 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > On Fri, 01 Jul 2005 13:39:22 +0100, Paul Howarth wrote: > > > >>If instead you have: > >> > >>%install > >>... > >>%clean > >>... > >>%check || : > >>... > >> > >>then old versions of rpm > > > > How old? > > rpm 4.0.something I think. Well before the dawn of Fedora. 4.2, which is available in RHL-9 and RHEL-3 and later. /usr/share/doc/rpm-*/CHANGES, https://bugzilla.redhat.com/64137 (I'll drop the "|| :" from spectemplate-perl.spec in the next fedora-rpmdevtools revision.) From kaboom at oobleck.net Fri Jul 1 15:29:18 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 1 Jul 2005 11:29:18 -0400 (EDT) Subject: Request for Review: ebtables In-Reply-To: <1119155461.10309.12.camel@localhost.localdomain> References: <1119155461.10309.12.camel@localhost.localdomain> Message-ID: On Sat, 18 Jun 2005, Tom 'spot' Callaway wrote: > ebtables: Ethernet Bridge frame table administration tool > > Ethernet bridge tables is a firewalling tool to transparantly filter > network traffic passing a bridge. The filtering possibilities are > limited to link layer filtering and some basic filtering on higher > network layers. > > The ebtables tool can be used together with the other Linux filtering > tools, like iptables. There are no known incompatibility issues. > > SPEC: http://www.auroralinux.org/people/spot/review/ebtables.spec > SRPM: > http://www.auroralinux.org/people/spot/review/ebtables-2.0.6-3.src.rpm > > The package has been tested on FC3 x86_64, and FC4 x86/ppc. > > Quite small, should be a quick review. Some changes to the spec: * missing PreReq for /sbin/chkconfig and /sbin/service * change %postun to if [ $1 -ge 1 ] /sbin/service ebtables condrestart > /dev/null 2>&1 ||: fi * might want to change /sbin to %{_sbindir} (since everything else is macro'ed) * "transparantly" is usually spelled "transparently" ;-) * I'd maybe change the %summary to something like "Tool for administering Linux kernel Ethernet frame filtering capabilities" (not that that's really short enough for a summary -- it should be something that says more about ebtables being the user-space admin for a kernel filter / firewall for frames I think). Maybe also indicate in the %description that this is administration of a kernel feature as well (just so it's clear that kernel support is required, etc) * the init script uses several config files that aren't included / %ghost'ed in the package: /etc/sysconfig/ebtables.filter /etc/sysconfig/ebtables.nat /etc/sysconfig/ebtables.broute (see below for this one) As for the init script, * sometimes references /etc/sysconfig/ebtables.route, sometimes references /etc/sysconfig/ebtables.broute. I think all of these should be broute * rpmlint says E: ebtables incoherent-subsys /etc/rc.d/init.d/ebtables $prog (because no lockfile defined) A few of those are blockers, but nothing too serious.... later, chris From ville.skytta at iki.fi Fri Jul 1 15:35:23 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 18:35:23 +0300 Subject: rpms/fish/devel fish.spec,1.1,1.2 In-Reply-To: <42C55DFF.3020808@linux-kernel.at> References: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> <20050701161035.621cf1fe.bugs.michael@gmx.net> <42C55185.90100@linux-kernel.at> <1120229995.2815.346.camel@localhost.localdomain> <42C55DFF.3020808@linux-kernel.at> Message-ID: <1120232123.2815.363.camel@localhost.localdomain> On Fri, 2005-07-01 at 17:15 +0200, Oliver Falk wrote: > On 07/01/2005 04:59 PM, Ville Skytt? wrote: > > On Fri, 2005-07-01 at 16:21 +0200, Oliver Falk wrote: > >>And you are correct, it doesn't improve package quality, but specfile > >>readability. :-) > > > > That's subjective. Many people find the "indented" style more readable, > > while others exactly the opposite. As long as there's no policy, it is > > up to the package _maintainer_ to decide, and _all others_ to respect. > > My fault, ok? Could we stop discussing a few spaces and tabs, as they > are whitespaces and whitespaces are 'nothing', so we are discussing > 'nothing'. :-P > > Don't get me wrong, I read and understood what you wrote! But we really > shouldn't discuss it too much... Right. And not committing that "nothing" is a good way to prevent null-content threads like this happening in the future :) From steve at silug.org Fri Jul 1 15:35:26 2005 From: steve at silug.org (Steven Pritchard) Date: Fri, 1 Jul 2005 10:35:26 -0500 Subject: Request for review: perl-Want In-Reply-To: <42C50C4C.3060001@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> Message-ID: <20050701153526.GA25201@osiris.silug.org> On Fri, Jul 01, 2005 at 11:26:36AM +0200, Oliver Falk wrote: > Also it suggests the following for make: > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" Is it really wise to override the options Perl was compiled with? It seems like I've asked this before, but I can't remember the answer. :) 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 kaboom at oobleck.net Fri Jul 1 15:32:28 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 1 Jul 2005 11:32:28 -0400 (EDT) Subject: Reviews still needed In-Reply-To: <1120228972.8990.172.camel@localhost.localdomain> References: <200507011419.j61EJgfd021141@ludwig-alpha.unil.ch> <1120228972.8990.172.camel@localhost.localdomain> Message-ID: On Fri, 1 Jul 2005, Tom 'spot' Callaway wrote: > Policy changed at FUDCon II. Basically, it is now ok for packages to not > build on some architectures, as long as its documented that they do not. Anything else of note change? later, chris From paul at city-fan.org Fri Jul 1 15:37:42 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 01 Jul 2005 16:37:42 +0100 Subject: Request for Review: ebtables In-Reply-To: References: <1119155461.10309.12.camel@localhost.localdomain> Message-ID: <42C56346.5030504@city-fan.org> Chris Ricker wrote: > Some changes to the spec: > > * missing PreReq for /sbin/chkconfig and /sbin/service > > * change %postun to > if [ $1 -ge 1 ] > /sbin/service ebtables condrestart > /dev/null 2>&1 ||: Or even: /sbin/service ebtables condrestart &> /dev/null || : > * might want to change /sbin to %{_sbindir} (since everything else is > macro'ed) %{_sbindir} usually expands to /usr/sbin, not /sbin Paul. From kaboom at oobleck.net Fri Jul 1 15:37:30 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 1 Jul 2005 11:37:30 -0400 (EDT) Subject: Request for Review: ebtables In-Reply-To: <42C56346.5030504@city-fan.org> References: <1119155461.10309.12.camel@localhost.localdomain> <42C56346.5030504@city-fan.org> Message-ID: On Fri, 1 Jul 2005, Paul Howarth wrote: > > * might want to change /sbin to %{_sbindir} (since everything else is > > macro'ed) > > %{_sbindir} usually expands to /usr/sbin, not /sbin Good point, ignore me on that one ;-) later, chris From ville.skytta at iki.fi Fri Jul 1 15:52:43 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 18:52:43 +0300 Subject: request for review: dirvish and required perl modules In-Reply-To: References: <1119898957.4656.68.camel@localhost.localdomain> Message-ID: <1120233163.2815.372.camel@localhost.localdomain> On Fri, 2005-07-01 at 10:54 -0400, Chris Ricker wrote: > On Mon, 27 Jun 2005, Ville Skytta wrote: > > > On Mon, 2005-06-27 at 13:34 -0400, Chris Ricker wrote: > > > > > > > > > Approved with the attached patch applied: > > - License is not Public Domain, except for some bits of Time::Timezone; > > Distributable is AFAICS the best we can state here. > > - Cosmetic: stuff not needed for noarch packages pruned, README added. > > > > Feel free to commit and I'll recheck and follow up with the approval > > message. > > Thanks, all changes applied and imported into devel Oops, one thing I missed: the "0." prefix should be removed from the package version. This isn't a snapshot version (and if it was one, the snapshot version identifier should be in release, not version). From bugs.michael at gmx.net Fri Jul 1 15:57:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 17:57:26 +0200 Subject: On spec file formatting/indentation (was: Re: rpms/fish/devel fish.spec,1.1,1.2) In-Reply-To: <42C55DFF.3020808@linux-kernel.at> References: <200507011108.j61B8aEI010707@cvs-int.fedora.redhat.com> <20050701161035.621cf1fe.bugs.michael@gmx.net> <42C55185.90100@linux-kernel.at> <1120229995.2815.346.camel@localhost.localdomain> <42C55DFF.3020808@linux-kernel.at> Message-ID: <20050701175726.2c03d97d.bugs.michael@gmx.net> On Fri, 01 Jul 2005 17:15:11 +0200, Oliver Falk wrote: > On 07/01/2005 04:59 PM, Ville Skytt? wrote: > > On Fri, 2005-07-01 at 16:21 +0200, Oliver Falk wrote: > >>And you are correct, it doesn't improve package quality, but specfile > >>readability. :-) > > > > That's subjective. Many people find the "indented" style more readable, > > while others exactly the opposite. As long as there's no policy, it is > > up to the package _maintainer_ to decide, and _all others_ to respect. > > My fault, ok? Could we stop discussing a few spaces and tabs, as they > are whitespaces and whitespaces are 'nothing', so we are discussing > 'nothing'. :-P > > Don't get me wrong, I read and understood what you wrote! But we really > shouldn't discuss it too much... We have to. We need to refresh things like this as they come up, since they are not covered by packaging policies/guidelines yet (afaik). It may become necessary to document a list of commonly encountered "need not fix" things in addition to "must fix" and "should fix" items. Some of us have made experience with the package QA procedures at fedora.us, where sometimes the difference between "must fix" blocker criteria and hints/suggestions was either not clear or non-existant, even when the infamous "QA checklist" contained only around 17 items. The procedures and processes at Fedora Extra are work in progress. We must ensure that the "reviewing" remains doable for the majority of packagers/contributors and that new contributors don't get a false impression of what is required and what remains packager's freedom. The notion of "minor moderating spec files" has come up in the past. "Indentation" and "spec template compliance" are things which can annoy a new [or even long-time] contributor easier than you would assume. It's not a big issue afterall, but it is brought up regularly, which may make all the new packagers wonder at which detail they need to adapt spec file formatting. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 2.24 2.04 1.57 From kaboom at oobleck.net Fri Jul 1 15:54:09 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 1 Jul 2005 11:54:09 -0400 (EDT) Subject: request for review: dirvish and required perl modules In-Reply-To: <1120233163.2815.372.camel@localhost.localdomain> References: <1119898957.4656.68.camel@localhost.localdomain> <1120233163.2815.372.camel@localhost.localdomain> Message-ID: On Fri, 1 Jul 2005, Ville Skytt? wrote: > Oops, one thing I missed: the "0." prefix should be removed from the > package version. This isn't a snapshot version (and if it was one, the > snapshot version identifier should be in release, not version). I did that because a version of 2003.1126 is ridiculous ;-) I'll change it though later, chris From orion at cora.nwra.com Fri Jul 1 15:57:20 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 01 Jul 2005 09:57:20 -0600 Subject: Request for Approval: hdf5 In-Reply-To: <42C41DA9.5060609@cora.nwra.com> References: <1119989530.3226.7.camel@localhost.localdomain> <1120002949.2513.7.camel@localhost.localdomain> <1120089574.2513.158.camel@localhost.localdomain> <42C41DA9.5060609@cora.nwra.com> Message-ID: <42C567E0.3040708@cora.nwra.com> Orion Poplawski wrote: > It compiles and tests fine on FC3, so perhaps it's a gcc 4.0.0 issue? > Not sure how easy it would be to cook up a small example that I could > send to the gcc folks. > Fixed the bug in the hdf5 code so it compiles and checks clean now. Will be submitting upstream. Latest versions: http://www.cora.nwra.com/~orion/fedora/hdf5-1.6.4-3.src.rpm http://www.cora.nwra.com/~orion/fedora/hdf5.spec Please review (and/or approve) -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rc040203 at freenet.de Fri Jul 1 16:04:47 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jul 2005 18:04:47 +0200 Subject: request for review: dirvish and required perl modules In-Reply-To: <1120233163.2815.372.camel@localhost.localdomain> References: <1119898957.4656.68.camel@localhost.localdomain> <1120233163.2815.372.camel@localhost.localdomain> Message-ID: <1120233887.3741.249.camel@mccallum.corsepiu.local> On Fri, 2005-07-01 at 18:52 +0300, Ville Skytt? wrote: > On Fri, 2005-07-01 at 10:54 -0400, Chris Ricker wrote: > > On Mon, 27 Jun 2005, Ville Skytta wrote: > > > > > On Mon, 2005-06-27 at 13:34 -0400, Chris Ricker wrote: > > > > > > > > > > > > > Approved with the attached patch applied: > > > - License is not Public Domain, except for some bits of Time::Timezone; > > > Distributable is AFAICS the best we can state here. > > > - Cosmetic: stuff not needed for noarch packages pruned, README added. > > > > > > Feel free to commit and I'll recheck and follow up with the approval > > > message. > > > > Thanks, all changes applied and imported into devel > > Oops, one thing I missed: the "0." prefix should be removed from the > package version. This isn't a snapshot version (and if it was one, the > snapshot version identifier should be in release, not version). 2 minor comments: 1. Same remark as it had been placed against one of my packages earlier today :) perl-Time-modules.spec inconsistently uses %__perl and make 2. Is the BuildRequires: perl >= 1:5.6.1 really necessary? I am going to approve this package, as the contents in CVS looks sufficent to me. Ralf From jamatos at fc.up.pt Fri Jul 1 16:09:18 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 01 Jul 2005 17:09:18 +0100 Subject: Request for review: pygsl References: <20050701160424.1b70f7e9.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > On Fri, 01 Jul 2005 12:48:25 +0100, Jos? Matos wrote: > >> http://www.fc.up.pt/pessoas/jamatos/pygsl.spec >> http://www.fc.up.pt/pessoas/jamatos/pygsl-0.3.2-1.src.rpm > > Hmm, may I add that it is preferred form during reviewing to bump release > with every package revision? I just arrived at Tom's review, clicked on > above link and found a spec file which doesn't match the reviewed > items. Believe me it was unintentional. Before sending the message I have placed the version that Tom saw, while using mock I found some of the mistakes that Tom pointed. I have upload the new version to a machine that sits in between and where I must run manually a script to force the update. I forgot it, my bad. After sending the message Tom saw the first version, since an update is done automatically before you look to it the second version replace the first. During all this time I was away from the computer... :-) > E.g. Tom points out that the pygsl directory is not included in the > package. Contrary to that, in the spec I see that the directory is > included, but no files at all: > > %files > %defattr(-,root,root) > %doc ChangeLog README CREDITS doc/ examples/ > %dir %{python_sitelib}/pygsl > > Should be: > > %files > %defattr(-,root,root) > %doc ChangeLog README CREDITS doc/ examples/ > %{python_sitelib}/pygsl/ You are right I knew that one of the lines implied the other and as usual I chose the wrong option. > [...] > > Without intentions to review this, I noticed: > > %install > python setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT > > Should be: > > %install > rm -rf $RPM_BUILD_ROOT > python setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT OK. Thank you. -- Jos? Ab?lio From orion at cora.nwra.com Fri Jul 1 16:15:28 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 01 Jul 2005 10:15:28 -0600 Subject: rpms/python-matplotlib/devel python-matplotlib.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <20050701003729.0f7398fd.bugs.michael@gmx.net> References: <200506302140.j5ULe9Ye024000@cvs-int.fedora.redhat.com> <20050701003729.0f7398fd.bugs.michael@gmx.net> Message-ID: <42C56C20.90909@cora.nwra.com> Michael Schwendt wrote: > On Thu, 30 Jun 2005 17:40:09 -0400, Orion Poplawski wrote: > > >>Author: orion >> >>Update of /cvs/extras/rpms/python-matplotlib/devel > > >>%files -f INSTALLED_FILES >>%defattr(-,root,root,-) >>%doc README license/LICENSE license/LICENSE_enthought.txt >>%doc license/LICENSE_PAINT license/LICENSE_PIL license/PYTZ_LICENSE.txt >>%doc API_CHANGES CHANGELOG CXX INSTALL INTERACTIVE KNOWN_BUGS >>%doc NUMARRAY_ISSUES PKG-INFO TODO >>%dir %{_libdir}/python2.4/site-packages/matplotlib > > > Here you likely want %{python_sitearch}/matplotlib instead, together with > this common way to define that path: > > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sy > sconfig import get_python_lib; print get_python_lib(1)")} > > Thanks! Committed. Question: will a devel build for this happen automatically? If not, how do I request? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From kaboom at oobleck.net Fri Jul 1 16:20:32 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 1 Jul 2005 12:20:32 -0400 (EDT) Subject: request for review: dirvish and required perl modules In-Reply-To: <1120233887.3741.249.camel@mccallum.corsepiu.local> References: <1119898957.4656.68.camel@localhost.localdomain> <1120233163.2815.372.camel@localhost.localdomain> <1120233887.3741.249.camel@mccallum.corsepiu.local> Message-ID: On Fri, 1 Jul 2005, Ralf Corsepius wrote: > 2 minor comments: > > 1. Same remark as it had been placed against one of my packages earlier > today :) > > perl-Time-modules.spec inconsistently uses %__perl and make See /usr/share/fedora/spectemplate-perl.spec which does the same > 2. Is the > BuildRequires: perl >= 1:5.6.1 > really necessary? I think it should pretty much work with perl-5.005+ (or maybe even older 5 series). I'll pull the version since any perl in any of the targeted distros is more than sufficient. later, chris From tcallawa at redhat.com Fri Jul 1 16:27:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 11:27:19 -0500 Subject: Request for Review: ebtables In-Reply-To: References: <1119155461.10309.12.camel@localhost.localdomain> Message-ID: <1120235239.8990.178.camel@localhost.localdomain> On Fri, 2005-07-01 at 11:29 -0400, Chris Ricker wrote: > Some changes to the spec: All changed in cvs (except for the sbin, that I actually had correct). Thanks! ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 1 16:32:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 11:32:41 -0500 Subject: Request for Approval: hdf5 In-Reply-To: <42C567E0.3040708@cora.nwra.com> References: <1119989530.3226.7.camel@localhost.localdomain> <1120002949.2513.7.camel@localhost.localdomain> <1120089574.2513.158.camel@localhost.localdomain> <42C41DA9.5060609@cora.nwra.com> <42C567E0.3040708@cora.nwra.com> Message-ID: <1120235561.8990.181.camel@localhost.localdomain> On Fri, 2005-07-01 at 09:57 -0600, Orion Poplawski wrote: > Orion Poplawski wrote: > > It compiles and tests fine on FC3, so perhaps it's a gcc 4.0.0 issue? > > Not sure how easy it would be to cook up a small example that I could > > send to the gcc folks. > > > > Fixed the bug in the hdf5 code so it compiles and checks clean now. > Will be submitting upstream. Good job. I can't review this package (because I wrote half of it), but it looks good to me. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 1 16:33:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 11:33:56 -0500 Subject: Request for review: perl-Want In-Reply-To: <20050701153526.GA25201@osiris.silug.org> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <20050701153526.GA25201@osiris.silug.org> Message-ID: <1120235636.8990.183.camel@localhost.localdomain> On Fri, 2005-07-01 at 10:35 -0500, Steven Pritchard wrote: > On Fri, Jul 01, 2005 at 11:26:36AM +0200, Oliver Falk wrote: > > Also it suggests the following for make: > > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > > Is it really wise to override the options Perl was compiled with? If perl wasn't compiled with $RPM_OPT_FLAGS, then thats a bug in Fedora Core. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Fri Jul 1 16:35:07 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 19:35:07 +0300 Subject: Request for review: perl-Want In-Reply-To: <20050701153526.GA25201@osiris.silug.org> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <20050701153526.GA25201@osiris.silug.org> Message-ID: <1120235707.2815.403.camel@localhost.localdomain> On Fri, 2005-07-01 at 10:35 -0500, Steven Pritchard wrote: > On Fri, Jul 01, 2005 at 11:26:36AM +0200, Oliver Falk wrote: > > Also it suggests the following for make: > > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > > Is it really wise to override the options Perl was compiled with? Well, there are a few things to consider, off the cuff in no particular order: The vast majority of non-noarch packages in the distro, not limited to Perl module ones, are built so that they honor $RPM_OPT_FLAGS. If a non-noarch Perl package does not honor $RPM_OPT_FLAGS, --target to rpmbuild will be completely ignored, and let's say folks explicitly asking for a i686 package will silently get a i386 one (which presents itself as an i686 one) when built on i386. The options have been overridden this way for a long time, and nobody has reported any related breakage. (And actually, by default, we're not even overriding anything, in the default configs we use for all shipped packages, $RPM_OPT_FLAGS is the same as what Perl would give. But that's kind of a coincidence.) ExtUtils::MakeMaker and Module::Build do provide means for overriding these options. > It seems like I've asked this before, but I can't remember the answer. :) The above doesn't really still answer that, but rather presents some food for thought why it might not be a wrong thing to do :) From bugs.michael at gmx.net Fri Jul 1 16:37:16 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 18:37:16 +0200 Subject: rpms/python-matplotlib/devel python-matplotlib.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <42C56C20.90909@cora.nwra.com> References: <200506302140.j5ULe9Ye024000@cvs-int.fedora.redhat.com> <20050701003729.0f7398fd.bugs.michael@gmx.net> <42C56C20.90909@cora.nwra.com> Message-ID: <20050701183716.5ab436e3.bugs.michael@gmx.net> On Fri, 01 Jul 2005 10:15:28 -0600, Orion Poplawski wrote: > Question: will a devel build for this happen automatically? No. > If not, how do I request? http://fedoraproject.org/wiki/Extras/BuildRequests From ville.skytta at iki.fi Fri Jul 1 16:36:33 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 19:36:33 +0300 Subject: rpms/python-matplotlib/devel python-matplotlib.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <42C56C20.90909@cora.nwra.com> References: <200506302140.j5ULe9Ye024000@cvs-int.fedora.redhat.com> <20050701003729.0f7398fd.bugs.michael@gmx.net> <42C56C20.90909@cora.nwra.com> Message-ID: <1120235793.2815.406.camel@localhost.localdomain> On Fri, 2005-07-01 at 10:15 -0600, Orion Poplawski wrote: > Question: will a devel build for this happen automatically? If not, > how do I request? http://fedoraproject.org/wiki/Extras/BuildRequests From ville.skytta at iki.fi Fri Jul 1 16:43:44 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Jul 2005 19:43:44 +0300 Subject: request for review: dirvish and required perl modules In-Reply-To: References: <1119898957.4656.68.camel@localhost.localdomain> <1120233163.2815.372.camel@localhost.localdomain> <1120233887.3741.249.camel@mccallum.corsepiu.local> Message-ID: <1120236224.2815.413.camel@localhost.localdomain> On Fri, 2005-07-01 at 12:20 -0400, Chris Ricker wrote: > > 2. Is the > > BuildRequires: perl >= 1:5.6.1 > > really necessary? > > I think it should pretty much work with perl-5.005+ (or maybe even older 5 > series). Historical note, only of academic interest nowadays: vendor install dirs are supported starting from Perl 5.6.1. From katzj at redhat.com Fri Jul 1 16:46:27 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 01 Jul 2005 12:46:27 -0400 Subject: request for review: mercurial Message-ID: <1120236387.25441.11.camel@bree.local.net> Since Xen is moving to using mercurial, I'm going to need to be able to run it to get at the repository so I figured I might as well package it up for Extras. Mercurial is a fast, lightweight source control management system designed for efficient handling of very large distributed projects. Features include: ... (okay, if you want to read the features, see the website -- http://www.selenic.com/mercurial/) SRPM and specfile at http://people.redhat.com/~katzj/mercurial/. Builds cleanly in mock and rpmlint seems happy with it. Comments? Jeremy From jamatos at fc.up.pt Fri Jul 1 16:54:59 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 01 Jul 2005 17:54:59 +0100 Subject: Request for review: pygsl References: <1120225220.8990.152.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: >> >> I have done all the process to become an FE packager. > > And I just sponsored you. Thank you. :-) >> -License: Although the project is GPL (it is clearly placed in the >> sources) there isn't no license in the source package. > > Find a copy of the GPL and put it in as Source1. OK. I copied emacs license file just to be sure. ;-) Done. I sent a message to pygsl mail list pointing this problem. >> -FC3: This version of pygsl does not compile in FC3 since it links to >> wavelets that are only present in gsl 1.6. Also the previous version >> 0.3.1 doesn't compile in FC4. > > Then you won't need an FC-3 branch for this package. :) I took the chance to warn the developers about this issue. Since I don't use FC3 anymore... :-) >> I have compile this using mock in i386 and x86_64 architecture without >> problems, the only complain of rpmlint is that: >> >> - there is no binary >> - several example files are not non executable scripts >> >> I think that these are harmless... > > Yeah, I think so too. > > Review of pygsl: > > rpmlint checks: > No output > > Bad: > - Prefix: %{_prefix} makes this package relocatable. If you really want > to do this, you have to make a good case in the request for review (see > the MUST on relocatable packages in > http://fedoraproject.org/wiki/PackageReviewGuidelines). You're probably > better off just removing this line. > > - Vendor and Packager fields are set, they should be removed. I have removed then since the spec file initially was generated using the distutils package. Done. > - Source0 is not presented as the URL for the upstream source. This is > important because reviewers need to check that the source in your SRPM > matches the upstream source. > Replace your existing Source0 line with: > Source0: http://dl.sourceforge.net/%{name}/%{name}-%{version}.tar.gz Done. > - /usr/lib/python2.4/site-packages/pygsl is not owned by the package, > when it should be (again, this is a byproduct of using a filelist for > python packages, it will not mark directories, only files) > Adding this line to the %files entry should do the trick: > %dir %{python_sitearch}/pysql I think that it should be like Michael wrote: %{python_sitearch}/pysql/ No? > You also need to add this line to the top of your spec (to safely use > %{python_sitearch}: > > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} Done that or else it would fail on x86_64... > - You need to include a copy of the License (GPL) in the package. You > can do this by downloading gpl.txt from: > > http://www.fsf.org/licensing/licenses/gpl.txt > > Then, you can add: > > Source1: gpl.txt > > In %build: > > cp %{SOURCE1} . > > And in %doc, add gpl.txt to the end of the existing line. Done. > (NOTE: You really want to push upstream to include the license text for > you, because without it, they're technically in violation of the GPL) Done. > Good: > - Package is named according to PackageNamingGuidelines > - spec file name matches %{name} > - License (GPL) OK, matches source license (but license is missing) > - Spec file is in Am. English, is legible > - Sources match upstream > - Package compiles and builds on x86 (FC4) > - No extra BuildRequires used > - All other build deps in BuildRequires > - No locales in spec files > - No need for -devel or -docs subpackages > - Permissions set correctly on files > - %clean section exists > - macro usage is consistent > - package is code, not content > - nothing in %doc affects runtime > - no static libraries > > You've got some work ahead of you, but it is your first package. Fix > those blocker items and I'll take another look at it. Ok, new version available: http://www.fc.up.pt/pessoas/jamatos/pygsl.spec http://www.fc.up.pt/pessoas/jamatos/pygsl-0.3.2-2.src.rpm And this I have verified that I have the right version. ;-) > Remember that http://fedoraproject.org/wiki/PackageNamingGuidelines, > http://fedoraproject.org/wiki/PackageReviewGuidelines and > http://www.fedoraproject.org/wiki/PackagingGuidelines are your > friends. :) Thank you for your support. :-) > ~spot -- Jos? Ab?lio From tcallawa at redhat.com Fri Jul 1 17:18:22 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 12:18:22 -0500 Subject: Request for review: pygsl In-Reply-To: References: <1120225220.8990.152.camel@localhost.localdomain> Message-ID: <1120238302.8990.198.camel@localhost.localdomain> On Fri, 2005-07-01 at 17:54 +0100, Jos? Matos wrote: > > - /usr/lib/python2.4/site-packages/pygsl is not owned by the package, > > when it should be (again, this is a byproduct of using a filelist for > > python packages, it will not mark directories, only files) > > Adding this line to the %files entry should do the trick: > > %dir %{python_sitearch}/pysql > > I think that it should be like Michael wrote: > %{python_sitearch}/pysql/ If you're not using the filelist, yes. If you're using the filelist, you just need to own the dir as well. > Ok, new version available: > http://www.fc.up.pt/pessoas/jamatos/pygsl.spec > http://www.fc.up.pt/pessoas/jamatos/pygsl-0.3.2-2.src.rpm > > And this I have verified that I have the right version. ;-) Minor item in the new spec: - You don't need two %setup lines. :) Since thats such a minor (and easy fix), consider it APPROVED with that change. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tian at c-sait.net Fri Jul 1 17:12:20 2005 From: tian at c-sait.net (Christian Jodar) Date: Fri, 1 Jul 2005 19:12:20 +0200 Subject: [Fwd: Prep Error: gcfilms-5_2-1 on development] In-Reply-To: <20050701140642.77522b1d.bugs.michael@gmx.net> References: <48051.83.145.93.226.1120205400.squirrel@83.145.93.226> <20050701140642.77522b1d.bugs.michael@gmx.net> Message-ID: <20050701191220.0ca1300c@tianbox> Thanks for your answers. > Right. That's why you may need to add %{?dist} to your spec, as > a) that makes "make tag" create a different tag for every branch, > and b) makes the binary rpms also get a different release tag, so > they upgrade eachother fine. You cannot have the same version-release > for multiple distributions and arch-specific and dist-specific rpms, > because that would violate the upgrade path. OK. I added the dist tag on devel version. I tagged it and requested a build. For the FC-4 branch, I already delivered versions without the dist tag. Won't there be any problem if I use it from now? Christian Jodar From bugs.michael at gmx.net Fri Jul 1 17:31:29 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 19:31:29 +0200 Subject: hping2 orphaned? Joining Extras In-Reply-To: <42B50566.6030102@verisignlabs.com> References: <42B486C2.8080107@verisignlabs.com> <20050618234831.66ae0b5c.bugs.michael@gmx.net> <42B50566.6030102@verisignlabs.com> Message-ID: <20050701193129.3711525f.bugs.michael@gmx.net> On Sun, 19 Jun 2005 01:40:54 -0400, Pete Toscano wrote: > Will sign the CLA on Monday, when I'm in the office. > > > 2) query http://bugzilla.redhat.com for possibly open bug reports > > which call for your attention as package maintainer, and present > > an updated package if necessary (for urgent fixes, it can be > > imported and built quickly by an existing contributor before > > your cvs account would be ready) > > Done. Found one report > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149776). I > haven't investigated this much yet, so I could be wrong, but it looks to > me that this guy's beef is with Salvatore Sanfilippo, the hping2 > maintainer. He should probably report a problem such as this on the > hping2 development lists, shouldn't he? That said, it looks like it > wouldn't be that hard of a problem to fix, so I might just submit a > patch to Salvatore. Okay. Sorry for the late reply. I'm facing a backlog of mail, as often I mark/flag some messages and plan to return to them later. Above bug report is from somebody, who uses an Intel compiler to test-build all of Extras (and possibly Core, too), because he believes Intel's compiler offers more detailed checking for warnings and errors. He then assumes that he can report all found issues in a single tracker, Fedora Extras bugzilla, where the many package owners then work like ants and forward such reports to the many many many upstream projects. It's something we have to live with. Some of the findings are real bugs, which can lead to malfunctioning code. Some are false positives, e.g. uninitialised variables in conjunctions with call by references, or compiled but unused (!) code sections. > I want to be sure I understand where our responsibilities lie as package > maintainers. It's our job to take the releases (and possibly useful > patches too) and bundle them up in RPMs for release in Extras, right? Yes. Plus, depending on upstream's release habits, you might want to evaluate the latest release some time before taking it as an update. > If a bug report comes in asking for code fixes or extra features > (possibly aside from already-existing patches) that don't involve the > packaging, the it's best to refer the submitter to the program's > development list, right? Yes, IMO. Even if you keep contact with the developers, for feature requests or requests for changed behaviour, it's best for end-users to propose changes in upstream's mailing-lists or bug trackers, so they are available in case questions are raised. > We're not expected to actively participate in > the program's development (although that wouldn't hurt). We should be > monitoring the programs we maintain for new releases and possibly for > some important patches. Does this about sum it up? Yes. You are free to participate in development or in creating patches for bugs, which are reported to you. Some packagers believe every oh-so-minor fix ought to be done upstream first. But I belong to those, who disagree with that. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.90 1.72 1.39 From bugs.michael at gmx.net Fri Jul 1 17:55:02 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jul 2005 19:55:02 +0200 Subject: [Fwd: Prep Error: gcfilms-5_2-1 on development] In-Reply-To: <20050701191220.0ca1300c@tianbox> References: <48051.83.145.93.226.1120205400.squirrel@83.145.93.226> <20050701140642.77522b1d.bugs.michael@gmx.net> <20050701191220.0ca1300c@tianbox> Message-ID: <20050701195502.18aa1fc6.bugs.michael@gmx.net> On Fri, 1 Jul 2005 19:12:20 +0200, Christian Jodar wrote: > Thanks for your answers. > > > Right. That's why you may need to add %{?dist} to your spec, as > > a) that makes "make tag" create a different tag for every branch, > > and b) makes the binary rpms also get a different release tag, so > > they upgrade eachother fine. You cannot have the same version-release > > for multiple distributions and arch-specific and dist-specific rpms, > > because that would violate the upgrade path. > > OK. I added the dist tag on devel version. I tagged it and requested a build. > > For the FC-4 branch, I already delivered versions without the dist tag. Won't > there be any problem if I use it from now? Currently: FC4: gcfilms-5.2-1 FC5: gcfilms-5.2-1.fc5 No problem there. All you must ensure is that version-release of a package for older distributions is _lower than_ version-release of the package for newer distributions. This is given for gcfilms. 5.2-1 < 5.2-1.fc5 How you achieve it for future updates is up to you. For some packages, it makes sense to use %{?dist}. For others, increasing %release is sufficiently fine. -- Michael Schwendt Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.35_FC3 loadavg: 1.88 2.03 1.99 From mricon at gmail.com Fri Jul 1 17:58:23 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 1 Jul 2005 13:58:23 -0400 Subject: Review for inclusion: diction In-Reply-To: <1120170761.8990.49.camel@localhost.localdomain> References: <1120170761.8990.49.camel@localhost.localdomain> Message-ID: On 30/06/05, Tom 'spot' Callaway wrote: > APPROVED Thanks, Tom! I've imported it into CVS -- both devel and FC4 branches. If someone sends an approval to the commits list, I'll request the builds. Cheers, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From oliver at linux-kernel.at Fri Jul 1 18:00:52 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 1 Jul 2005 20:00:52 +0200 Subject: On spec file formatting/indentation (was: Re: rpms/fish/devel fish.spec, 1.1, 1.2) In-Reply-To: <20050701175726.2c03d97d.bugs.michael@gmx.net> Message-ID: <200507011800.j61I0pXr020984@mail.linux-kernel.at> > On Fri, 01 Jul 2005 17:15:11 +0200, Oliver Falk wrote: > > > On 07/01/2005 04:59 PM, Ville Skytt? wrote: > > > On Fri, 2005-07-01 at 16:21 +0200, Oliver Falk wrote: > > >>And you are correct, it doesn't improve package quality, but > > >>specfile readability. :-) > > > > > > That's subjective. Many people find the "indented" style more > > > readable, while others exactly the opposite. As long as > there's no > > > policy, it is up to the package _maintainer_ to decide, > and _all others_ to respect. > > > > My fault, ok? Could we stop discussing a few spaces and > tabs, as they > > are whitespaces and whitespaces are 'nothing', so we are discussing > > 'nothing'. :-P > > > > Don't get me wrong, I read and understood what you wrote! But we > > really shouldn't discuss it too much... > > We have to. We need to refresh things like this as they come > up, since they are not covered by packaging > policies/guidelines yet (afaik). It may become necessary to > document a list of commonly encountered "need not fix" > things in addition to "must fix" and "should fix" items. Some > of us have made experience with the package QA procedures at > fedora.us, where sometimes the difference between "must fix" > blocker criteria and hints/suggestions was either not clear > or non-existant, even when the infamous "QA checklist" > contained only around 17 items. The procedures and processes > at Fedora Extra are work in progress. We must ensure that the > "reviewing" remains doable for the majority of > packagers/contributors and that new contributors don't get a > false impression of what is required and what remains > packager's freedom. The notion of "minor moderating spec > files" has come up in the past. "Indentation" and "spec > template compliance" are things which can annoy a new [or > even long-time] contributor easier than you would assume. > > It's not a big issue afterall, but it is brought up > regularly, which may make all the new packagers wonder at > which detail they need to adapt spec file formatting. It was nothing I suggested to Axel. Yes, I did allready and I was asked not to do it again, because it's not 'relevant'. So I don't recommend it any more... As Axel has no CVS account yet and I was the one who actually imported and requested build for him, I felt free to do some identation, because it was the reason why I didn't look for the dist macro... Some kind of pattern matchin' algorithm in my brain get's confused if no identation is done. :-\ However, it was 'wrong' to do this and I got it, of course....... I *do* understand, that changin' the spec without maintainers permission is wrong, but see the above explanation (again) why I did this. But keep in mind, if I would have changed the identation *before* cvs-import, you would never have recognized it. :-P However, as long as Axel has no cvs account - or better said no cvs sponsor - I'm the one who has to/is going to maintain the packages and I thought it's not too wrong to change some identation. Now I know that this wasn't a very good idea and will not do it again and I guess the discussion made it's way to the brains of others as well and that's what you actually wanted/started this 'discussion'/briefing/introduction for - didn't you? :-) And this is Ok from my side. So finally, I'd like to give you three characters: ACK. :-) Best, Oliver From jamatos at fc.up.pt Fri Jul 1 18:00:45 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 01 Jul 2005 19:00:45 +0100 Subject: New package: matplotlib References: Message-ID: Hi Orion, I have packaged matplotlib before and I have split the package in three: - matplotlib - python-pytz - python-dateutils Would you consider to do that. The question is that matplotlib includes the code for those two packages, and those are distinct projects. Both of them are usefull outside matplotlib. I'm sorry I know that I should asked this before but as I stated before I was busy. :-( Regards, -- Jos? Ab?lio From orion at cora.nwra.com Fri Jul 1 18:13:32 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 01 Jul 2005 12:13:32 -0600 Subject: New package: matplotlib (upstream packages that include other projects -- what to do?) In-Reply-To: References: Message-ID: <42C587CC.20505@cora.nwra.com> Jos? Matos wrote: > Hi Orion, > I have packaged matplotlib before and I have split the package in three: > > - matplotlib > - python-pytz > - python-dateutils > > Would you consider to do that. The question is that matplotlib includes > the code for those two packages, and those are distinct projects. > > Both of them are usefull outside matplotlib. > > I'm sorry I know that I should asked this before but as I stated before I > was busy. :-( > > Regards, I might. There is some other source in there as well I think. It's something that was bugging me, and I'm facing the same issue with the basemap extension that provides a python interface to proj.4 (along with the full proj.4 source). Other comments welcome. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From tcallawa at redhat.com Fri Jul 1 18:15:02 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 01 Jul 2005 13:15:02 -0500 Subject: Request for Review: Rekall and dependencies In-Reply-To: <20050701151404.GA8953@lisas.de> References: <1119238318.11411.8.camel@localhost.localdomain> <20050701151404.GA8953@lisas.de> Message-ID: <1120241702.27103.2.camel@localhost.localdomain> On Fri, 2005-07-01 at 17:14 +0200, Adrian Reber wrote: > + source matches upstream > + builds in mock > + -devel subpackage with .a, .so, headers and documentation > > - builds not on my system because of missing BR: doxygen > > According to http://fedoraproject.org/buildgroups/4/i386/buildroots.xml > doxygen is part of build and therefore it works in mock. But as it is > not part of > http://fedoraproject.org/wiki/PackagingGuidelines#head-5e0efda65c4d4266d60c269ced6ea1c28051cb6e > I think it has to be added. Agreed. Fixed. > Maybe only the html documentation or the latex should be part of the > package and not both. Especially as the tex files are not compiled it > probably makes more sense to only include the html docs. Fixed. New SPEC: http://www.auroralinux.org/people/spot/review/xbase.spec New SRPM: http://www.auroralinux.org/people/spot/review/xbase-2.0.0-2.src.rpm Please review. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Fri Jul 1 18:19:38 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 01 Jul 2005 13:19:38 -0500 Subject: request for review: mercurial In-Reply-To: <1120236387.25441.11.camel@bree.local.net> (Jeremy Katz's message of "Fri, 01 Jul 2005 12:46:27 -0400") References: <1120236387.25441.11.camel@bree.local.net> Message-ID: >>>>> "JK" == Jeremy Katz writes: JK> Comments? I don't think it gets much simpler or cleaner than that. Is it generally accepted that this error: extracting debug info from /var/tmp/mercurial-0.6-1-root/usr/lib/python2.3/site-packages/mercurial/bdiff.so Only dest dir longer than base dir not supported during the find-debuginfo step of package building is to be ignored? - J< From jpo at di.uminho.pt Fri Jul 1 18:58:34 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Fri, 01 Jul 2005 19:58:34 +0100 Subject: Request for review: perl-Want (Update to 0.09) In-Reply-To: <1120208445.3741.127.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> Message-ID: <42C5925A.8020109@di.uminho.pt> Ralf, > Files: > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Want-0.08-1.src.rpm > > Review (and approval) appreciated, TIA There is already a new version in CPAN ;) Diff http://search.cpan.org/diff?from=Want-0.08&to=Want-0.09 jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mark.bidewell at alumni.clemson.edu Fri Jul 1 19:06:11 2005 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Fri, 01 Jul 2005 15:06:11 -0400 Subject: Firestarter RPM selinux errors Message-ID: <42C59423.8030709@alumni.clemson.edu> The firestarter RPM cause selinux errors on shutdown and other errors on startup. These errors have ben tracked down to the line "sh /etc/firestarter/firestarter.sh start" which starts firestarter independent of the firestater init script. Removing this line solves the selinux errors and the firewall policy still seems to be in effect. I am theroizing that the line above is executed when the dhclient daemon attempts to shutdown as well as start thus attempting to start the firewall while closing the interface. I think this is what selinux is flagging. The line also causes some errors on interface startup. Does this line have a useful purpose? Mark Bidewell From j.w.r.degoede at hhs.nl Fri Jul 1 19:14:51 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jul 2005 21:14:51 +0200 Subject: Review request: svgalib Message-ID: <42C5962B.8070004@hhs.nl> Hi all, Description: The svgalib package provides the SVGAlib low-level graphics library for Linux. SVGAlib is a library which allows applications to use full screen graphics on a variety of hardware platforms. Some games and utilities use SVGAlib for their graphics. For details on supported chipsets, see man 7 svgalib (when svgalib is installed). A few attempts for an svgalib package have been done before at fedora.us, but they never got enough attention to get through the review process, mostly because the current Fedora was forming and taking everybodies attention. Differences from the last try: - Upstream has reintroduced suid root use in 1.9.20 as an alternative to the helper-kernel-module. This allows us to build a sane (kernel module free) package of the 1.9 (devel) versions. The 1.4 (stable) versions haven't seen an update in ages and don't support most modern cards -> Update to the latest upstream devel release 1.9.21 . - Split the Debian patches in some sane parts, redo against 1.9.21 where nescesarry - Don't patch Makefile.cfg instead just pass the nescesarry options to make in %%build and %%install - Reintroduce %%_smp_mflags, this seems to work fine with 1.9.21 You can find this attempt at: http://home.versatel.nl/jwrdegoede/svgalib.spec http://home.versatel.nl/jwrdegoede/svgalib-1.9.21-1.src.rpm Thanks & Regards, Hans From katzj at redhat.com Fri Jul 1 19:27:38 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 01 Jul 2005 15:27:38 -0400 Subject: request for review: mercurial In-Reply-To: References: <1120236387.25441.11.camel@bree.local.net> Message-ID: <1120246058.25441.14.camel@bree.local.net> On Fri, 2005-07-01 at 13:19 -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jeremy Katz writes: > JK> Comments? > > I don't think it gets much simpler or cleaner than that. I try :-) > Is it generally accepted that this error: > > extracting debug info from /var/tmp/mercurial-0.6-1-root/usr/lib/python2.3/site-packages/mercurial/bdiff.so > Only dest dir longer than base dir not supported > > during the find-debuginfo step of package building is to be ignored? I vaguely remember distutils of FC3 (which I'm guessing you're on based on python 2.3) not passing -g in CFLAGS and so this would happen. I don't get it on my machine (rawhide). Jeremy From notting at redhat.com Fri Jul 1 19:32:39 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jul 2005 15:32:39 -0400 Subject: Review request: svgalib In-Reply-To: <42C5962B.8070004@hhs.nl> References: <42C5962B.8070004@hhs.nl> Message-ID: <20050701193239.GA15800@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Differences from the last try: > - Upstream has reintroduced suid root use in 1.9.20 as an alternative to > the helper-kernel-module. This allows us to build a sane (kernel > module free) package of the 1.9 (devel) versions. The 1.4 (stable) > versions haven't seen an update in ages and don't support most modern > cards -> Update to the latest upstream devel release 1.9.21 . Um, *ewww*. Excesses of setuid binaries just seems bad. Bill From tibbs at math.uh.edu Fri Jul 1 19:44:19 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 01 Jul 2005 14:44:19 -0500 Subject: request for review: mercurial In-Reply-To: <1120246058.25441.14.camel@bree.local.net> (Jeremy Katz's message of "Fri, 01 Jul 2005 15:27:38 -0400") References: <1120236387.25441.11.camel@bree.local.net> <1120246058.25441.14.camel@bree.local.net> Message-ID: >>>>> "JK" == Jeremy Katz writes: JK> I vaguely remember distutils of FC3 (which I'm guessing you're on JK> based on python 2.3) not passing -g in CFLAGS and so this would JK> happen. Yes, I'm at FC3 currently. Repackaging all of my local crap for each new release takes some time so I've yet to upgrade. JK> I don't get it on my machine (rawhide). Good enough for me. ACK. - J< From j.w.r.degoede at hhs.nl Fri Jul 1 20:25:15 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jul 2005 22:25:15 +0200 Subject: Review request: svgalib In-Reply-To: <20050701193239.GA15800@nostromo.devel.redhat.com> References: <42C5962B.8070004@hhs.nl> <20050701193239.GA15800@nostromo.devel.redhat.com> Message-ID: <42C5A6AB.5060406@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > >>Differences from the last try: >>- Upstream has reintroduced suid root use in 1.9.20 as an alternative to >> the helper-kernel-module. This allows us to build a sane (kernel >> module free) package of the 1.9 (devel) versions. The 1.4 (stable) >> versions haven't seen an update in ages and don't support most modern >> cards -> Update to the latest upstream devel release 1.9.21 . > > > Um, *ewww*. Excesses of setuid binaries just seems bad. > If it aint broken don't fix it :) svgalib apps are pretty safe as long as they are coded correctly: int main(...) { vga_init(); ... ... } vga_init will mmap parts of /dev/mem and do an iopl(3), followed by dropping all priviliges. Also many distros (Debian and others) still ship 1.4.3 which works the same way and RedHat has also shipped svgalib in this mode for a long time. There have been serious bugs in both svgalib and apps using it, but those have all been fixed and no new ones have come up for a while. I currently don't have any plans to add svgalib using apps to Fedora-Extras, so no suid binaires will be added by me :) I use svgalib for some projects of my own which I unfortunatly can't add to fedora-extras. So there may never be apps in Fedoro-Extras using svgalib, although I hope having svgalib available will inspire others to add apps, it will atleast make this a whole lot easier. I wanted a package of svgalib since I've become to dislike manual installed sw, and now that I've taken the time to create one I might as well share it. Once some apps have been added we can see if the suid stuff is a real concern and ifso switch to the helper-kernel-module setup, with all the package maintainer problems this adds. Regards, Hans From andreas.bierfert at lowlatency.de Fri Jul 1 22:40:01 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 02 Jul 2005 00:40:01 +0200 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> Message-ID: <42C5C641.6000908@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 thank you very much... I will get this sorted out and get back to you sunday evening CET... - -Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCxcZBQEQyPsWM8csRAo2KAKCI48NMLty41CHk5nHS5T3/8UYqBwCePvUC aDwm4QM7EammwWsUhvTMyOI= =74AP -----END PGP SIGNATURE----- From jpo at di.uminho.pt Sat Jul 2 01:05:01 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 02 Jul 2005 02:05:01 +0100 Subject: Request for review: perl-Text-Glob In-Reply-To: <1120222603.3741.213.camel@mccallum.corsepiu.local> References: <1120222603.3741.213.camel@mccallum.corsepiu.local> Message-ID: <42C5E83D.3090700@di.uminho.pt> Ralf, > > Files: > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Text-Glob.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Text-Glob-0.06-1.src.rpm > I have the same perl module in Fedora.us. Please see it for a much more readable specfile using Module::Build. Fedora.us ticket https://bugzilla.fedora.us/show_bug.cgi?id=2360 Signed SRPM http://gsd.di.uminho.pt/jpo/perl/SRPMS/perl-Text-Glob-0.06-0.fdr.2.src.rpm jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Sat Jul 2 01:09:18 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 02 Jul 2005 02:09:18 +0100 Subject: Request for review: perl-File-Find-Rule In-Reply-To: <1120222651.3741.216.camel@mccallum.corsepiu.local> References: <1120222651.3741.216.camel@mccallum.corsepiu.local> Message-ID: <42C5E93E.3080806@di.uminho.pt> Ralf, > > Files: > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-File-Find-Rule.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-File-Find-Rule-0.06-1.src.rpm ^^^^ ??? I have the same perl module in Fedora.us. Please see it for a much more readable specfile using Module::Build. Fedora.us ticket https://bugzilla.fedora.us/show_bug.cgi?id=2361 Signed SRPM http://gsd.di.uminho.pt/jpo/perl/SRPMS/perl-File-Find-Rule-0.28-0.fdr.2.src.rpm jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Sat Jul 2 01:12:07 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 02 Jul 2005 02:12:07 +0100 Subject: Request for review: perl-Devel-StackTrace In-Reply-To: <1120222775.3741.218.camel@mccallum.corsepiu.local> References: <1120222775.3741.218.camel@mccallum.corsepiu.local> Message-ID: <42C5E9E7.4030500@di.uminho.pt> Ralf, > Files: > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Devel-StackTrace.spec > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Devel-StackTrace-1.11-1.src.rpm Same thing for this module. Fedora.us https://bugzilla.fedora.us/show_bug.cgi?id=1082 Signed SRPM http://gsd.di.uminho.pt/jpo/perl/SRPMS/perl-Devel-StackTrace-1.11-0.fdr.3.src.rpm jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Sat Jul 2 01:42:14 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 02 Jul 2005 02:42:14 +0100 Subject: Request for review: perl-WWW-Mechanize (and buildreqs) Message-ID: <42C5F0F6.3060100@di.uminho.pt> Name : perl-WWW-Mechanize Summary : Automates web page form & link interaction Description : "WWW::Mechanize", or Mech for short, helps you automate interaction with a website. It supports performing a sequence of page fetches including following links and submitting forms. Each fetched page is parsed and its links and forms are extracted. A link or a form can be selected, form fields can be filled and the next page can be fetched. Mech also stores a history of the URLs you've visited, which can be queried and revisited. http://gsd.di.uminho.pt/jpo/software/fedora/perl-WWW-Mechanize.spec http://gsd.di.uminho.pt/jpo/software/fedora/perl-WWW-Mechanize-1.12-2.src.rpm Buid requirements ----------------- Summary: Perl extension for comparing arrays http://gsd.di.uminho.pt/jpo/software/fedora/perl-Array-Compare.spec http://gsd.di.uminho.pt/jpo/software/fedora/perl-Array-Compare-1.12-3.src.rpm Summary: Class for representing nodes in a tree http://gsd.di.uminho.pt/jpo/software/fedora/perl-Tree-DAG_Node.spec http://gsd.di.uminho.pt/jpo/software/fedora/perl-Tree-DAG_Node-1.05-2.src.rpm Summary: Perl extension to test methods for warnings http://gsd.di.uminho.pt/jpo/software/fedora/perl-Test-Warn.spec http://gsd.di.uminho.pt/jpo/software/fedora/perl-Test-Warn-0.08-2.src.rpm Summary: Tools to test taintedness http://gsd.di.uminho.pt/jpo/software/fedora/perl-Test-Taint.spec http://gsd.di.uminho.pt/jpo/software/fedora/perl-Test-Taint-1.04-2.src.rpm Additional notes ---------------- 1) Dependency tree: https://bugzilla.fedora.us/showdependencytree.cgi?id=2432 2) perl-WWW-Mechanize is also a RT requirement jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Sat Jul 2 01:58:24 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 02 Jul 2005 02:58:24 +0100 Subject: Request for Review: libevent In-Reply-To: <20050617172333.19754b5e@nausicaa.camperquake.de> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> Message-ID: <42C5F4C0.2000700@di.uminho.pt> Ralf, >>>%build >>>%configure \ >>> --disable-dependency-tracking >> >>Really? Call me paranoid, but I'd rather leave that out. > > I am not a configure guru, the help mentioned that it speeds up > one-time builds (which rpm does). I also vote for dropping "--disable-dependency-tracking" from the configure line. The -r option can also dropped in the following line: rm -rf $RPM_BUILD_ROOT%{_libdir}/*.la Everything else looks good. Feel free to import it into the Extras' CVS. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Sat Jul 2 04:18:08 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jul 2005 06:18:08 +0200 Subject: Request for Review: libevent In-Reply-To: <42C5F4C0.2000700@di.uminho.pt> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> <42C5F4C0.2000700@di.uminho.pt> Message-ID: <1120277888.3741.269.camel@mccallum.corsepiu.local> On Sat, 2005-07-02 at 02:58 +0100, Jos? Pedro Oliveira wrote: > Ralf, > > >>>%build > >>>%configure \ > >>> --disable-dependency-tracking > >> > >>Really? Call me paranoid, but I'd rather leave that out. > > > > I am not a configure guru, the help mentioned that it speeds up > > one-time builds (which rpm does). > > I also vote for dropping "--disable-dependency-tracking" from the > configure line. All --disable-dependency-tracking does is switch of automake's internal file dependency tracking inside of automake-generated makefiles and thereby speed up builds [1]. As dependency tracking is a developer feature being used during development and should be irrelevant during packaging, it normally is safe to switch if off during "production builts" on a buildsystem for the sake of building speed. So, whether to use or not on FE "production builts", basically is a matter of personal taste, complexity of a package and available hardware resources. I for one, recommend using --disable-dependency-tracking for "production builts" if it gives a measurable/significant speedup [2]. Using it on trivial packages is more or less pointless. Ralf [1] The speed up can reach several magnitudes. [2] I know about large/complex packages, where the influence of --disable-dependency-tracking results into several dozens of minutes speed up. From rc040203 at freenet.de Sat Jul 2 04:35:17 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jul 2005 06:35:17 +0200 Subject: Request for review: perl-Text-Glob In-Reply-To: <42C5E83D.3090700@di.uminho.pt> References: <1120222603.3741.213.camel@mccallum.corsepiu.local> <42C5E83D.3090700@di.uminho.pt> Message-ID: <1120278918.3741.280.camel@mccallum.corsepiu.local> On Sat, 2005-07-02 at 02:05 +0100, Jos? Pedro Oliveira wrote: > Ralf, > > > > Files: > > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Text-Glob.spec > > ftp://packman.iu-bremen.de/fedora/SRPMS/perl-Text-Glob-0.06-1.src.rpm > > > > I have the same perl module in Fedora.us. Please see it > for a much more readable specfile using Module::Build. Your spec-file is formated differently and uses a different approach to configuring the package, but "much more readable" is a matter of personal taste ... Ralf From mike at flyn.org Sat Jul 2 05:49:51 2005 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 2 Jul 2005 00:49:51 -0500 Subject: Review request: roundup bug tracker Message-ID: <20050702054951.GA20327@imp.flyn.org> Name: roundup Description: Roundup is a simple and flexible issue-tracking system with command line, web and email interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. http://www.flyn.org/SRPMS/roundup-0.8.3-1.src.rpm http://www.flyn.org/SRPMS/roundup.spec Some things that I am unsure of: 1. SELinux does not allow Apache to execute CGI scripts in /usr/share/roundup/cgi-bin/. How is this solved (SELinux policy is monolithic)? 2. Should installing the package restart Apache so that /etc/httpd/conf.d/roundup.conf is read? 3. How should one handle initializing the Roundup database in MySQL? I think this needs to be done by hand instead of in a %post script. -- Mike :wq From ville.skytta at iki.fi Sat Jul 2 08:18:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 02 Jul 2005 11:18:45 +0300 Subject: Request for Review: libevent In-Reply-To: <1120277888.3741.269.camel@mccallum.corsepiu.local> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> <42C5F4C0.2000700@di.uminho.pt> <1120277888.3741.269.camel@mccallum.corsepiu.local> Message-ID: <1120292325.26373.6.camel@localhost.localdomain> On Sat, 2005-07-02 at 06:18 +0200, Ralf Corsepius wrote: > I for one, recommend using --disable-dependency-tracking for "production > builts" if it gives a measurable/significant speedup [2]. In addition to potential speedups, the build output becomes somewhat more legible with dependency tracking disabled. From jamatos at fc.up.pt Sat Jul 2 09:40:37 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Sat, 02 Jul 2005 10:40:37 +0100 Subject: Request for review: pygsl References: <1120225220.8990.152.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: > http://www.fsf.org/licensing/licenses/gpl.txt > > Then, you can add: > > Source1: gpl.txt > > In %build: > > cp %{SOURCE1} . > > And in %doc, add gpl.txt to the end of the existing line. > > (NOTE: You really want to push upstream to include the license text for > you, because without it, they're technically in violation of the GPL) I sent a message to the pygsl mailing list and I got a prompt reply. The file is already in cvs for next version: http://cvs.sourceforge.net/viewcvs.py/pygsl/pygsl/COPYING?rev=1.1&view=auto I have renamed the license file accordingly to its name on the project. :-) -- Jos? Ab?lio From ville.skytta at iki.fi Sat Jul 2 11:22:48 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 02 Jul 2005 14:22:48 +0300 Subject: Trademarks Message-ID: <1120303368.26373.30.camel@localhost.localdomain> Should one acknowledge trademarks somehow in all package summaries and descriptions in Extras? I think yes, but I don't see this mentioned in the Wiki anywhere, and there are many packages that would need to be updated wrt. this. For example, I'm committing an update to the kernel-module-thinkpad in a jiffy, with the following summary and description. Would this be ok/needed in all packages that refer to US/other trademarks, or is it possible to have a "blanket trademark acknowledgement" somewhere? Or something else? (The last blurb below comes from Lenovo's trademark usage guidelines.) ---- Summary: Supplemental kernel modules for ThinkPad? laptop computers %description This package contains kernel modules that interface the System Management Application Program Interface (SMAPI) BIOS found in some ThinkPad? laptop computers, and drivers for certain ThinkPad hardware components. ThinkPad is a registered trademark of Lenovo in the United States, other countries, or both. From jamatos at fc.up.pt Sat Jul 2 11:35:53 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Sat, 02 Jul 2005 12:35:53 +0100 Subject: Request for review: pygsl References: <1120225220.8990.152.camel@localhost.localdomain> <1120238302.8990.198.camel@localhost.localdomain> Message-ID: Tom 'spot' Callaway wrote: > Since thats such a minor (and easy fix), consider it APPROVED with that > change. OK. I sent an approval message to the commits list as required. I have an account in the wiki "jamatos" and I think that I need to wait to be added to some group there to be able to edit the page asking for a bugzilla component. Meanwhile I will import the package into cvs. > ~spot -- Jos? Ab?lio From gajownik at fedora.pl Sat Jul 2 12:15:49 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 02 Jul 2005 14:15:49 +0200 Subject: Request for Approval: Nessus packages In-Reply-To: <1120098101.7350.7.camel@fluffbox.fluffnet> References: <1120098101.7350.7.camel@fluffbox.fluffnet> Message-ID: <42C68575.3050909@fedora.pl> Dnia 06/30/2005 04:21 AM, U?ytkownik Kyle Pointer napisa?: > If someone would at least look at them I would greatly appreciate it. Christian pointed you almost all problems :) I'll add: - timestamps in SRPMs are not preserved: http://fedoraproject.org/wiki/PackagingGuidelines#Timestamps - use "%setup -q -n %{name}" "cd nessus-libraries" will be not needed then. - missing BuildRequires: use fedora-rmdevelrpms http://fedoraproject.org/wiki/PackagingGuidelines#Requires You should also take a look at nessus-config and nasl-config scripts (--cflags and --libs options) - try to use system libraries: http://fedoraproject.org/wiki/PackagingGuidelines#SystemLibraryDuplication You should use "--disable-nessuspcap" option (BTW --disable-static would be also nice) - when it's possible, turn on parallel building: http://fedoraproject.org/wiki/PackagingGuidelines#parallelmake (libnasl does not like it) - use rpmlint: it's a very useful tool :) http://fedoraproject.org/wiki/PackagingGuidelines#rpmlint I have made libnasl.spec and nessus-libraries.spec: http://80.55.221.90/~gajownik/linux/RPMS/nessus/ -- feel free to use them ;) I'm a dumb packager and I know almost nothing about C/C++ programming, so I'm afraid of taking responsibility for maintaining programs in Fedora Extras :P BTW may someone review my specs? I could have done something stupid :/ There is one glitch with libnasl: should I redefine _localstatedir to /var/lib like it's done in PLD's spec file? rpmlint does not like nessus_org.pem in /var/nessus/ :/ Right now I'm fighting with nessus-core.spec :D I think that you should split this package into client and daemon. I don't know how to name them: - like in Debian: nessusd and nessus - like in PLD/Mandriva: nessusd and nessus-client Should client package provide only GTK+ client (like in Debian) or both GTK+ and text client (like in PLD/Mandriva)? http://search.rpmseek.com/search.html?hl=com&cs=nessus:PN:0:0:0:0 I'll try to make rest of spec files. Oh, and the last question: should I use %{__make} macro or simle "make" is sufficient? Dawid -- ^_* From tcallawa at redhat.com Sat Jul 2 13:06:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 02 Jul 2005 08:06:33 -0500 Subject: Trademarks In-Reply-To: <1120303368.26373.30.camel@localhost.localdomain> References: <1120303368.26373.30.camel@localhost.localdomain> Message-ID: <1120309593.27103.35.camel@localhost.localdomain> On Sat, 2005-07-02 at 14:22 +0300, Ville Skytt? wrote: > Should one acknowledge trademarks somehow in all package summaries and > descriptions in Extras? I think yes, but I don't see this mentioned in > the Wiki anywhere, and there are many packages that would need to be > updated wrt. this. > > For example, I'm committing an update to the kernel-module-thinkpad in a > jiffy, with the following summary and description. Would this be > ok/needed in all packages that refer to US/other trademarks, or is it > possible to have a "blanket trademark acknowledgement" somewhere? Or > something else? I suspect that what you've done is correct, but it should be run past RH legal. Greg, what does legal want us to do with regards to other people's trademarks? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Sat Jul 2 13:29:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 2 Jul 2005 09:29:32 -0400 Subject: Review request: roundup bug tracker In-Reply-To: <20050702054951.GA20327@imp.flyn.org> References: <20050702054951.GA20327@imp.flyn.org> Message-ID: <20050702132932.GA16181@jadzia.bu.edu> On Sat, Jul 02, 2005 at 12:49:51AM -0500, W. Michael Petullo wrote: > 1. SELinux does not allow Apache to execute CGI scripts in > /usr/share/roundup/cgi-bin/. How is this solved (SELinux policy is > monolithic)? Yeah, executables should't go in /usr/share. > 2. Should installing the package restart Apache so that > /etc/httpd/conf.d/roundup.conf is read? No, it shouldn't. (*Maybe* a 'service httpd graceful', but hey, you're already having to do a bunch of this by hand anyway...) > 3. How should one handle initializing the Roundup database in MySQL? > I think this needs to be done by hand instead of in a %post script. I think CGI scripts (and PHP apps) make difficult RPMs that need a whole bunch of weird special-casing.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From i.pilcher at comcast.net Sat Jul 2 14:33:43 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 02 Jul 2005 09:33:43 -0500 Subject: Trademarks In-Reply-To: <1120303368.26373.30.camel@localhost.localdomain> References: <1120303368.26373.30.camel@localhost.localdomain> Message-ID: Ville Skytt? wrote: > Summary: Supplemental kernel modules for ThinkPad? laptop computers I would recommend sticking to straight ASCII, maybe ThinkPad(R)? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From andreas at bawue.net Sat Jul 2 14:45:23 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 2 Jul 2005 16:45:23 +0200 (CEST) Subject: Trademarks In-Reply-To: References: <1120303368.26373.30.camel@localhost.localdomain> Message-ID: On Sat, 2 Jul 2005, Ian Pilcher wrote: > Ville Skytt? wrote: > > Summary: Supplemental kernel modules for ThinkPad? laptop computers > I would recommend sticking to straight ASCII, maybe ThinkPad(R)? At least. But if we decide to mentioning each and every trademark (pandora's box most likely) we shouldn't do so in the spec. Put a TRADEMARKS file or something into the package %doc tag. bye, andreas From otaylor at redhat.com Sat Jul 2 16:00:51 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 02 Jul 2005 12:00:51 -0400 Subject: Trademarks In-Reply-To: <1120303368.26373.30.camel@localhost.localdomain> References: <1120303368.26373.30.camel@localhost.localdomain> Message-ID: <1120320051.6623.17.camel@localhost.localdomain> On Sat, 2005-07-02 at 14:22 +0300, Ville Skytt? wrote: > Should one acknowledge trademarks somehow in all package summaries and > descriptions in Extras? I think yes, but I don't see this mentioned in > the Wiki anywhere, and there are many packages that would need to be > updated wrt. this. > > For example, I'm committing an update to the kernel-module-thinkpad in a > jiffy, with the following summary and description. Would this be > ok/needed in all packages that refer to US/other trademarks, or is it > possible to have a "blanket trademark acknowledgement" somewhere? Or > something else? [ Insert "not a lawyer" disclaimer ] My understanding is that there is no obligation to acknowledge trademarks in this sort of descriptive use. The worry I'd have about acknowledging *some* trademarks, is that there might be an implication that things that we don't acknowledge aren't trademarks. And having to acknowledge Linux, GNOME, KDE, etc, could clutter up the package descriptions just a bit :-) Regards, Owen -------------- 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 andreas at bawue.net Sat Jul 2 16:29:52 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 2 Jul 2005 18:29:52 +0200 (CEST) Subject: Trademarks In-Reply-To: <1120320051.6623.17.camel@localhost.localdomain> References: <1120303368.26373.30.camel@localhost.localdomain> <1120320051.6623.17.camel@localhost.localdomain> Message-ID: On Sat, 2 Jul 2005, Owen Taylor wrote: > My understanding is that there is no obligation to acknowledge > trademarks in this sort of descriptive use. If you're right, that would be great. > The worry I'd have about acknowledging *some* trademarks, is that there > might be an implication that things that we don't acknowledge aren't > trademarks. Full ack. Starting to acknowledge trademarks would most likely come down to opening Pandora's box. We would have to check for every package name if it might be a trademark. We would have to check if the description mentions a name which might be a trademark (e.g. name is a implementation of something(R) protocol). And the big danger is, the moment one of these trademarks is overlooked, someone might construct an accusation of willfull trademark violation, as we never mentioned his trademark. Can of worms, don't go there. > And having to acknowledge Linux, GNOME, KDE, etc, could clutter up > the package descriptions just a bit :-) Fun fact: Even projects with a trademarked name (bacula comes to mind) do not have a funky (R) symbol in the %description tag in the RPMS they ship. bye, andreas From steve at silug.org Sat Jul 2 19:30:13 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 2 Jul 2005 14:30:13 -0500 Subject: ddrescue and dd_rescue In-Reply-To: References: <42C4FE44.5010108@redhat.com> <1120206990.2815.222.camel@localhost.localdomain> <42C51D38.4050101@redhat.com> Message-ID: <20050702193013.GA15992@osiris.silug.org> On Fri, Jul 01, 2005 at 12:53:25PM +0200, Andreas Thienemann wrote: > I'll just testdrive both packages and we'll see which one is better. The problem is they both have their good points. Personally, I'm starting to think that having both ddrescue and dd_rescue, as well as dd_rhelp (a front-end to dd_rescue that I happen to have a package for) would be good. 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 andreas at bawue.net Sat Jul 2 20:43:50 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 2 Jul 2005 22:43:50 +0200 (CEST) Subject: ddrescue and dd_rescue In-Reply-To: <20050702193013.GA15992@osiris.silug.org> References: <42C4FE44.5010108@redhat.com> <1120206990.2815.222.camel@localhost.localdomain> <42C51D38.4050101@redhat.com> <20050702193013.GA15992@osiris.silug.org> Message-ID: On Sat, 2 Jul 2005, Steven Pritchard wrote: > > I'll just testdrive both packages and we'll see which one is better. > The problem is they both have their good points. I start to agree. I looked at both packages yesterday, and they both have their strong points. And they are quite different. ddrescue has much better documentation (although the dd_rescue package I prepared has the third party manpage). dd_rescue has better reporting of progress and is a bit more flexible as it accepts a bit more command line arguments which control it's operations. During my testcase it also seemed a bit faster. ddrescue however is way more comfortable when errors are encountered as it already has the ability to skip the errors and inch closer to the defect from both ends of the drive. This is only achievable with dd_rescue when using dd_rhelp. > Personally, I'm starting to think that having both ddrescue and > dd_rescue, as well as dd_rhelp (a front-end to dd_rescue that I happen > to have a package for) would be good. Personally, I do not care anymore, just like Warren. ;) I'm happy to package both and also maintain the ddrescue and the dd_rescue package as well. If you'd send me your dd_rhelp package, I'll do that as well. Only question: what's the policy of fedora-extra with regard to similar packages? Opinions? bye, andreas From Fedora at TQMcube.com Sat Jul 2 21:21:04 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Sat, 02 Jul 2005 17:21:04 -0400 Subject: Maintainer? Message-ID: <1120339264.5954.3.camel@dch.TQMcube.com> Given that I am already providing a leafnode rpm on our website and that the original maintainer is AWOL, I completed a Redhat cvs access form. Is that all I need to do for now in order to ultimately maintain leafnode for FE? -- * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From oliver at linux-kernel.at Sat Jul 2 22:11:05 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sun, 3 Jul 2005 00:11:05 +0200 Subject: Maintainer? In-Reply-To: <1120339264.5954.3.camel@dch.TQMcube.com> Message-ID: <200507022211.j62MB0Y5008594@mail.linux-kernel.at> David Cary Hart wrote: > Given that I am already providing a leafnode rpm on our > website and that > the original maintainer is AWOL, I completed a Redhat cvs access form. > Is that all I need to do for now in order to ultimately maintain > leafnode for FE? You'll need a CVS sponser first. If you have allready applied for an cvs account at https://admin.fedora.redhat.com/accounts/, it's now time to way for someone to sponsor you, or you find someone who is going to do it... Best, Oliver From ghenry at suretecsystems.com Sat Jul 2 22:43:54 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 2 Jul 2005 23:43:54 +0100 Subject: New Package: Sprog Message-ID: <200507022344.03123.ghenry@suretecsystems.com> Dear List, I really love Sprog, so I have packaged it up (well, rewritten the supplied specfile). "Sprog is a tool for working with data. It allows you to do all the things those clever Unix geeks can do with their cryptic command lines but you can now do it all with point-n-click and drag-n-drop. A Sprog machine has many similarities to a shell script. It is built from small reusable parts (called gears) that are connected together to filter and massage your data. Once you have built a machine, you can save it and run it again and again to automatically perform repetitive tasks." It uses perl and Gtk2, amongst others. SRPM: http://www.perl.me.uk/downloads/Sprog/Sprog-0.12-1.src.rpm SPEC: http://www.perl.me.uk/downloads/Sprog/Sprog.spec Main Site: http://sprog.sourceforge.net/ Article: http://www.perl.com/pub/a/2005/06/23/sprog.html Anyone care to review it? jpo? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Sat Jul 2 22:56:12 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sun, 03 Jul 2005 00:56:12 +0200 Subject: Request for Approval: Nessus packages In-Reply-To: Your message of "Sat, 02 Jul 2005 14:15:49 +0200." <42C68575.3050909@fedora.pl> Message-ID: <200507022330.j62NUnfs027908@mx2.redhat.com> Hi Dawid, gajownik at fedora.pl said: > Should client package provide only GTK+ client (like in Debian) or both > GTK+ and text client (like in PLD/Mandriva)? Well, if I can have my say: I'd say both :-) > Oh, and the last question: should I use %{__make} macro or simle "make" is > sufficient? The preferred form is: %{__make} %{?_smp_mflags} Cheers, Christian From ghenry at suretecsystems.com Sat Jul 2 22:58:03 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 2 Jul 2005 23:58:03 +0100 Subject: New Package: Sprog In-Reply-To: <200507022344.03123.ghenry@suretecsystems.com> References: <200507022344.03123.ghenry@suretecsystems.com> Message-ID: <200507022358.08580.ghenry@suretecsystems.com> On Saturday 02 Jul 2005 23:43, Gavin Henry wrote: > Dear List, > > I really love Sprog, so I have packaged it up (well, rewritten the supplied > specfile). > > "Sprog is a tool for working with data. It allows you to do all the things > those clever Unix geeks can do with their cryptic command lines but you can > now do it all with point-n-click and drag-n-drop. > > A Sprog machine has many similarities to a shell script. It is built from > small reusable parts (called gears) that are connected together to filter > and massage your data. Once you have built a machine, you can save it and > run it again and again to automatically perform repetitive tasks." > > It uses perl and Gtk2, amongst others. > > SRPM: http://www.perl.me.uk/downloads/Sprog/Sprog-0.12-1.src.rpm > SPEC: http://www.perl.me.uk/downloads/Sprog/Sprog.spec > > Main Site: http://sprog.sourceforge.net/ > Article: http://www.perl.com/pub/a/2005/06/23/sprog.html > > Anyone care to review it? Sorry, I need to build for extras: perl-Apache-LogRegex perl-Gnome2-Canvas perl-Gtk2-GladeXML perl-Imager They'll be done tomorrow. > jpo? > > Thanks, > > Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Sat Jul 2 23:06:22 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sun, 03 Jul 2005 01:06:22 +0200 Subject: ddrescue and dd_rescue In-Reply-To: Your message of "Sat, 02 Jul 2005 22:43:50 +0200." Message-ID: <200507022341.j62Nf1n7028622@mx2.redhat.com> andreas at bawue.net said: > Opinions? How about put them all (ddrescue + dd_rescue + dd_rhelp) in a single package ? I think it would be the least confusing, with the two explanation paragraphs you just wrote slapped in a README... CHF 0.02 ... :-) (2 cents of a swiss franc) Christian From ivazquez at ivazquez.net Sat Jul 2 23:25:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 02 Jul 2005 19:25:35 -0400 Subject: Request for Approval: Nessus packages In-Reply-To: <42C68575.3050909@fedora.pl> References: <1120098101.7350.7.camel@fluffbox.fluffnet> <42C68575.3050909@fedora.pl> Message-ID: <1120346735.26858.1.camel@ignacio.ignacio.lan> On Sat, 2005-07-02 at 14:15 +0200, Dawid Gajownik wrote: > Should client package provide only GTK+ client (like in Debian) or both > GTK+ and text client (like in PLD/Mandriva)? -client should have the text client. -client-gtk should have the GTK+ client. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ghenry at suretecsystems.com Sat Jul 2 23:26:09 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 3 Jul 2005 00:26:09 +0100 Subject: New Package: perl-Apache-LogRegex Message-ID: <200507030026.10119.ghenry@suretecsystems.com> Dear List, perl-Apache-LogRegex for Sprog dependancies. SRPM: http://www.perl.me.uk/downloads/modules/perl-Apache-LogRegex-1.2-1.src.rpm SPEC: http://www.perl.me.uk/downloads/modules/perl-Apache-LogRegex.spec Main Site: http://sprog.sourceforge.net/ Article: http://www.perl.com/pub/a/2005/06/23/sprog.html Anyone care to review it? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From bugs.michael at gmx.net Sat Jul 2 23:42:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Jul 2005 01:42:38 +0200 Subject: Request for Approval: Nessus packages In-Reply-To: <200507022330.j62NUnfs027908@mx2.redhat.com> References: <42C68575.3050909@fedora.pl> <200507022330.j62NUnfs027908@mx2.redhat.com> Message-ID: <20050703014238.09698063.bugs.michael@gmx.net> On Sun, 03 Jul 2005 00:56:12 +0200, Christian.Iseli at licr.org wrote: > Hi Dawid, > > gajownik at fedora.pl said: > > Should client package provide only GTK+ client (like in Debian) or both > > GTK+ and text client (like in PLD/Mandriva)? > > Well, if I can have my say: I'd say both :-) > > > Oh, and the last question: should I use %{__make} macro or simle "make" is > > sufficient? > > The preferred form is: > %{__make} %{?_smp_mflags} Use simple "make", but add SMP make flags unless they cause make to fail. It is up to you whether you like %__make more than plain "make". $ rpm --eval %__make /usr/bin/make Considering that "make" has been in standard path for ages, is expected to be in there and is not expected to move, %{__make} would be overuse of macros, plays in the same league as: $ rpm --eval %__rm /bin/rm $ rpm --eval %__cp /bin/cp $ rpm --eval %__mkdir_p /bin/mkdir -p $ rpm --eval %__install /usr/bin/install $ rpm --eval %__perl /usr/bin/perl $ rpm --eval %__python /usr/bin/python $ rpm --eval %__gzip /usr/bin/gzip $ rpm --eval %__bzip2 /usr/bin/bzip2 and others. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.12-1.1387_FC4 loadavg: 2.25 2.23 2.15 From bugs.michael at gmx.net Sat Jul 2 23:58:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Jul 2005 01:58:55 +0200 Subject: Maintainer? In-Reply-To: <200507022211.j62MB0Y5008594@mail.linux-kernel.at> References: <1120339264.5954.3.camel@dch.TQMcube.com> <200507022211.j62MB0Y5008594@mail.linux-kernel.at> Message-ID: <20050703015855.01b82f7f.bugs.michael@gmx.net> On Sun, 3 Jul 2005 00:11:05 +0200, Oliver Falk wrote: > David Cary Hart wrote: > > Given that I am already providing a leafnode rpm on our > > website and that > > the original maintainer is AWOL, I completed a Redhat cvs access form. > > Is that all I need to do for now in order to ultimately maintain > > leafnode for FE? > > You'll need a CVS sponser first. If you have allready applied for an cvs > account at https://admin.fedora.redhat.com/accounts/, it's now time to way > for someone to sponsor you, or you find someone who is going to do it... I'm going to sponsor David, but there has not been any notification about a new cvsextras account needing a sponsor over the past hours. So, patience, for now. After having mailed back the signed Fedora CLA as instructed by the accounts system, new contributors must add themselves to the respective groups in which they want an account. "cvsextras" in this case. The main page explains this. With regard to taking over ownership of the leafnode package, the "leafnode" component entry in bugzilla will be transferred to David. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.12-1.1387_FC4 loadavg: 2.30 2.42 2.29 From andreas at bawue.net Sun Jul 3 00:18:53 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sun, 3 Jul 2005 02:18:53 +0200 (CEST) Subject: ddrescue and dd_rescue In-Reply-To: <200507022341.j62Nf1n7028622@mx2.redhat.com> References: <200507022341.j62Nf1n7028622@mx2.redhat.com> Message-ID: On Sun, 3 Jul 2005 Christian.Iseli at licr.org wrote: > How about put them all (ddrescue + dd_rescue + dd_rhelp) in a single package ? > I think it would be the least confusing, with the two explanation paragraphs > you just wrote slapped in a README... I could do that as well... But I prefer single packages. Furthermore: What to name the package? dd_rescue? ddrescue? And why is ddrescue included in dd_rescue or vice versa? I fear that's unecessary confusion of the user. bye, andreas From mpeters at mac.com Sun Jul 3 04:14:06 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 02 Jul 2005 21:14:06 -0700 Subject: Request for review: pyxdg In-Reply-To: <1119957451.21475.5.camel@localhost.localdomain> References: <1119957451.21475.5.camel@localhost.localdomain> Message-ID: <1120364046.2685.16.camel@locolhost.localdomain> On Tue, 2005-06-28 at 13:17 +0200, Sindre Pedersen Bjordal wrote: * snip smeg - I'll review that later when I've played with it* > > For dependencies: PyXDG, a python library to access freedesktop.org > standards. Used Rudolfs spec from Newrpms and adapted it to the > fedora template. > > http://foolish.digitalinc.info/pakker/SRPMS/pyxdg.spec > http://foolish.digitalinc.info/pakker/SRPMS/pyxdg-0.14-1.src.rpm upstream md5sum matches License is correct according to COPYING file builds in mock cleanly (fc4) spec file is in style of fedora-rpmdevtools template HOWEVER - This appears to me to be a noarch package. Add builarch: noarch change CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build to just %{__python} setup.py build (a C compiler is not used) I also would suggest adding %{?dist} to the release From wtogami at redhat.com Sun Jul 3 06:07:50 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 03 Jul 2005 08:07:50 +0200 Subject: ddrescue and dd_rescue In-Reply-To: <20050702193013.GA15992@osiris.silug.org> References: <42C4FE44.5010108@redhat.com> <1120206990.2815.222.camel@localhost.localdomain> <42C51D38.4050101@redhat.com> <20050702193013.GA15992@osiris.silug.org> Message-ID: <42C780B6.5070808@redhat.com> Steven Pritchard wrote: > On Fri, Jul 01, 2005 at 12:53:25PM +0200, Andreas Thienemann wrote: > >>I'll just testdrive both packages and we'll see which one is better. > > > The problem is they both have their good points. > > Personally, I'm starting to think that having both ddrescue and > dd_rescue, as well as dd_rhelp (a front-end to dd_rescue that I happen > to have a package for) would be good. > Since you are familiar with both and also have a supplemental package, does this mean you would like to become the owner? =) Warren From wtogami at redhat.com Sun Jul 3 06:31:40 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 03 Jul 2005 08:31:40 +0200 Subject: ddrescue and dd_rescue In-Reply-To: References: <200507022341.j62Nf1n7028622@mx2.redhat.com> Message-ID: <42C7864C.4000002@redhat.com> Andreas Thienemann wrote: > On Sun, 3 Jul 2005 Christian.Iseli at licr.org wrote: > > >>How about put them all (ddrescue + dd_rescue + dd_rhelp) in a single package ? >>I think it would be the least confusing, with the two explanation paragraphs >>you just wrote slapped in a README... > > I could do that as well... > But I prefer single packages. > Furthermore: What to name the package? dd_rescue? ddrescue? And why is > ddrescue included in dd_rescue or vice versa? > > I fear that's unecessary confusion of the user. > This entire situation of two upstreams, nearly identical in function, with almost the same name, is unnecessary confusion to users. Warren Togami wtogami at redhat.com From byte at aeon.com.my Sun Jul 3 07:57:09 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 03 Jul 2005 15:57:09 +0800 Subject: nvu Message-ID: <1120377429.3772.410.camel@potter.soho.bytebot.net> So, its released and there was interest in this back in March (started by Seth), and Gavin Henry seemed interested in getting a spec written. Then Chris Aillon said he had something being worked on, but we haven't seen anything yet Is anyone interested in packaging nvu? -- Colin Charles, http://www.bytebot.net/ From andreas at bawue.net Sun Jul 3 11:06:03 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sun, 3 Jul 2005 13:06:03 +0200 (CEST) Subject: ddrescue and dd_rescue In-Reply-To: <42C7864C.4000002@redhat.com> References: <200507022341.j62Nf1n7028622@mx2.redhat.com> <42C7864C.4000002@redhat.com> Message-ID: On Sun, 3 Jul 2005, Warren Togami wrote: > This entire situation of two upstreams, nearly identical in function, > with almost the same name, is unnecessary confusion to users. That too... From oliver at linux-kernel.at Sun Jul 3 11:31:01 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sun, 3 Jul 2005 13:31:01 +0200 Subject: Maintainer? In-Reply-To: <20050703015855.01b82f7f.bugs.michael@gmx.net> Message-ID: <200507031130.j63BUtIX032113@mail.linux-kernel.at> Michael Schwendt wrote: > On Sun, 3 Jul 2005 00:11:05 +0200, Oliver Falk wrote: > > > David Cary Hart wrote: > > > Given that I am already providing a leafnode rpm on our > > > website and > > > that the original maintainer is AWOL, I completed a Redhat cvs > > > access form. > > > Is that all I need to do for now in order to ultimately maintain > > > leafnode for FE? > > > > You'll need a CVS sponser first. If you have allready > > applied for an > > cvs account at https://admin.fedora.redhat.com/accounts/, it's now > > time to way for someone to sponsor you, or you find someone > who is going to do it... > > I'm going to sponsor David, but there has not been any > notification about a new cvsextras account needing a sponsor > over the past hours. So, patience, for now. > > After having mailed back the signed Fedora CLA as instructed > by the accounts system, new contributors must add themselves > to the respective groups in which they want an account. > "cvsextras" in this case. The main page explains this. > > With regard to taking over ownership of the leafnode package, > the "leafnode" component entry in bugzilla will be > transferred to David. Fine, Michael. Thanks for acting! Best, Oliver From ivazquez at ivazquez.net Sun Jul 3 11:40:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 03 Jul 2005 07:40:39 -0400 Subject: nvu In-Reply-To: <1120377429.3772.410.camel@potter.soho.bytebot.net> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> Message-ID: <1120390839.26858.4.camel@ignacio.ignacio.lan> On Sun, 2005-07-03 at 15:57 +0800, Colin Charles wrote: > So, its released and there was interest in this back in March (started > by Seth), and Gavin Henry seemed interested in getting a spec written. > Then Chris Aillon said he had something being worked on, but we haven't > seen anything yet > > Is anyone interested in packaging nvu? I suppose the first person to get it to actually build gets to maintain it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 caillon at redhat.com Sun Jul 3 11:55:50 2005 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 03 Jul 2005 07:55:50 -0400 Subject: nvu In-Reply-To: <1120377429.3772.410.camel@potter.soho.bytebot.net> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> Message-ID: <42C7D246.7070905@redhat.com> On 07/03/2005 03:57 AM, Colin Charles wrote: >So, its released and there was interest in this back in March (started >by Seth), and Gavin Henry seemed interested in getting a spec written. >Then Chris Aillon said he had something being worked on, but we haven't >seen anything yet > >Is anyone interested in packaging nvu? > > https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00012.html From dennis at ausil.us Sun Jul 3 12:23:19 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 3 Jul 2005 07:23:19 -0500 Subject: build failure In-Reply-To: <20050701140727.3eec4c10.bugs.michael@gmx.net> References: <200506302318.34588.dennis@ausil.us> <20050701140727.3eec4c10.bugs.michael@gmx.net> Message-ID: <200507030723.29609.dennis@ausil.us> Once upon a time Friday 01 July 2005 7:07 am, Michael Schwendt wrote: > It would give the same results. What you would need is a copy of the > config.log, as most likely the configure script once again failed to find > Qt in /usr/lib64/qt-3.3/lib and either looked in /usr/lib64/qt-3.3/lib64 > or somewhere else. I've seen this before and fixed it in some packages, > but I don't have an x86_64 machine for real experiments. For a > trial-and-error fix attempt, try copying from amarok.spec, where I chose > to set $QTLIB and $QTINC to make it build, so we could move on. If that > doesn't fix it, a closer look might be necessary (also examining build > behaviour in multilib installations). i have an X86_64 box that i run mythtv on. its got FC3 so ill see what i can do. i thought for starters i would just rebuild it and see how it goes. it got through configure and is building now. was there something changed between FC3 and FC4 that would affect this? ill install mock on the machine and try an FC4 build. though hdd is nearly always full :( -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sun Jul 3 12:48:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Jul 2005 14:48:06 +0200 Subject: build failure In-Reply-To: <200507030723.29609.dennis@ausil.us> References: <200506302318.34588.dennis@ausil.us> <20050701140727.3eec4c10.bugs.michael@gmx.net> <200507030723.29609.dennis@ausil.us> Message-ID: <20050703144806.5675139e.bugs.michael@gmx.net> On Sun, 3 Jul 2005 07:23:19 -0500, Dennis Gilmore wrote: > Once upon a time Friday 01 July 2005 7:07 am, Michael Schwendt wrote: > > > It would give the same results. What you would need is a copy of the > > config.log, as most likely the configure script once again failed to find > > Qt in /usr/lib64/qt-3.3/lib and either looked in /usr/lib64/qt-3.3/lib64 > > or somewhere else. I've seen this before and fixed it in some packages, > > but I don't have an x86_64 machine for real experiments. For a > > trial-and-error fix attempt, try copying from amarok.spec, where I chose > > to set $QTLIB and $QTINC to make it build, so we could move on. If that > > doesn't fix it, a closer look might be necessary (also examining build > > behaviour in multilib installations). > i have an X86_64 box that i run mythtv on. its got FC3 so ill see what i > can do. i thought for starters i would just rebuild it and see how it goes. > it got through configure and is building now. was there something changed > between FC3 and FC4 that would affect this? ill install mock on the machine > and try an FC4 build. though hdd is nearly always full :( Well, I'm not aware of any fundamental changes. But on x86_64 I've seen "configure" scripts do weird things with a $kdelibsuff variable, such as appending it in places where it leads to wrong paths like the aforementioned QTLIB location. Whether this happens only in mock or also in normal x86_64 systems, is something for interested x86_64 supporters to find out. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1400_FC5 loadavg: 0.13 0.24 0.63 From tcallawa at redhat.com Sun Jul 3 14:10:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Jul 2005 09:10:51 -0500 Subject: Reviews still needed In-Reply-To: <200507011519.j61FJ09e021727@ludwig-alpha.unil.ch> References: <200507011519.j61FJ09e021727@ludwig-alpha.unil.ch> Message-ID: <1120399851.27103.53.camel@localhost.localdomain> On Fri, 2005-07-01 at 17:19 +0200, Christian.Iseli at licr.org wrote: > tcallawa at redhat.com said: > > Policy changed at FUDCon II. Basically, it is now ok for packages to not > > build on some architectures, as long as its documented that they do not. > > Ok. In that case, the questions I asked in > https://www.redhat.com/archives/fedora-extras-list/2005-June/msg00488.html > still stand (except for the compiler warnings, which can be ignored for x86 :-) All of those issues are now resolved in CVS. Care to re-review (or approve)? :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From j.w.r.degoede at hhs.nl Sun Jul 3 16:34:50 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jul 2005 18:34:50 +0200 Subject: mmap question Message-ID: <42C813AA.2080404@hhs.nl> Hi all, I'm busy trying to package svgalib-1.9.x for Fedora-Extras (I know I'm also mailing to devel). And I've hit a bit of a bump. svgalib-1.9.x mmap's part of the linear framebuffer at the same address each time vga_setpage gets called. This is done for cards which are not 100% vga compatible, so that old programs which expect to see banked modes will get banked modes emulated. The problem with this is that in order todo this svgalib leaves the fd for /dev/mem open. Which of course is a big nono from a security point of view. So I've been tracking all uses of the /dev/mem fd and I'm almost so far that it can be closed immediatly after calling vga_init or vga_setmode, as it used to be done in the 1.4.x series. The setpage emulation on linearframebuffers is the last problem I have. What I would like todo is: open /dev/mem mmap the entire lfb close /dev/mem mmap part of the lfb (64k) at a random address, using the mmap of the entire lfb as source instead of an fd. mmap another part of the lfb (64k) at the address the previous part had. So what I want is something like mremap, which will allow me to: -specify a new offset into the file instead of a new size. or a mmap which will take an existing mapping as source rather then an fd. Thus such a beast exist and or can anyone help me with another solution? Thanks & Regards, Hans From arjanv at redhat.com Sun Jul 3 16:53:57 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 03 Jul 2005 18:53:57 +0200 Subject: mmap question In-Reply-To: <42C813AA.2080404@hhs.nl> References: <42C813AA.2080404@hhs.nl> Message-ID: <1120409637.3164.55.camel@laptopd505.fenrus.org> > The problem with this is that in order todo this svgalib leaves the fd > for /dev/mem open. Which of course is a big nono from a security point > of view. In fedora that's actually not THAT bad actually; still not too good tho As for your question; there is a fremap which may do what you want, but the use of it is a bit tricky sort of so I'm not sure if you really want to do that. -------------- 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 adrian at lisas.de Sun Jul 3 17:01:52 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 3 Jul 2005 19:01:52 +0200 Subject: Request for Review: Rekall and dependencies In-Reply-To: <1120241702.27103.2.camel@localhost.localdomain> References: <1119238318.11411.8.camel@localhost.localdomain> <20050701151404.GA8953@lisas.de> <1120241702.27103.2.camel@localhost.localdomain> Message-ID: <20050703170152.GA14452@lisas.de> On Fri, Jul 01, 2005 at 01:15:02PM -0500, Tom 'spot' Callaway wrote: > New SPEC: http://www.auroralinux.org/people/spot/review/xbase.spec > New SRPM: > http://www.auroralinux.org/people/spot/review/xbase-2.0.0-2.src.rpm > > Please review. :) + md5sum matches upstream + rpmlint almost doesn't complain + builds clean in mock + BR are correct + SPEC looks good + clean installation and removal + correct usage of -devel sub-package + scripts look good + all binaries are starting (couldn't test; don't have any db files) APPROVED Adrian From dennis at ausil.us Sun Jul 3 18:32:19 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 3 Jul 2005 13:32:19 -0500 Subject: konversation build failure Message-ID: <200507031332.26008.dennis@ausil.us> ok i fixed x86_64 build but got an error on ppc Rebuild source rpm konversation-0.18-4.fc5.src.rpm ERROR: something went wrong rebuilding the .src.rpm ERROR: inspect rpm build log /var/tmp/mach/fedora-development-ppc-core/konversation-0.18-4.fc5/rpm.log ERROR: failed to rebuild SRPMs is that a build system issue? should i resubmit or can i get the rpm.log to see what happened? and try and work it out. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun Jul 3 19:56:36 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jul 2005 21:56:36 +0200 Subject: mmap question In-Reply-To: <1120409637.3164.55.camel@laptopd505.fenrus.org> References: <42C813AA.2080404@hhs.nl> <1120409637.3164.55.camel@laptopd505.fenrus.org> Message-ID: <42C842F4.3090308@hhs.nl> Arjan van de Ven wrote: >>The problem with this is that in order todo this svgalib leaves the fd >>for /dev/mem open. Which of course is a big nono from a security point >>of view. > > > In fedora that's actually not THAT bad actually; still not too good tho > Could you explain this a bit? > As for your question; there is a fremap which may do what you want, but > the use of it is a bit tricky sort of so I'm not sure if you really want > to do that. > Hmm, that might to the trick, why wouldn't I want todo that? And what about doing tricks with /proc/self/mem? Thanks ! & Regards, Hans From arjanv at redhat.com Sun Jul 3 21:13:18 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 03 Jul 2005 23:13:18 +0200 Subject: mmap question In-Reply-To: <42C842F4.3090308@hhs.nl> References: <42C813AA.2080404@hhs.nl> <1120409637.3164.55.camel@laptopd505.fenrus.org> <42C842F4.3090308@hhs.nl> Message-ID: <1120425198.3164.67.camel@laptopd505.fenrus.org> On Sun, 2005-07-03 at 21:56 +0200, Hans de Goede wrote: > > Arjan van de Ven wrote: > >>The problem with this is that in order todo this svgalib leaves the fd > >>for /dev/mem open. Which of course is a big nono from a security point > >>of view. > > > > > > In fedora that's actually not THAT bad actually; still not too good tho > > > Could you explain this a bit? try doing "interesting" things with /dev/mem and you'll see what I mean ;) -------------- 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 ghenry at suretecsystems.com Sun Jul 3 21:22:07 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 3 Jul 2005 22:22:07 +0100 Subject: New Package: Sprog In-Reply-To: <200507022344.03123.ghenry@suretecsystems.com> References: <200507022344.03123.ghenry@suretecsystems.com> Message-ID: <200507032222.08277.ghenry@suretecsystems.com> On Saturday 02 Jul 2005 23:43, Gavin Henry wrote: > Dear List, > > I really love Sprog, so I have packaged it up (well, rewritten the supplied > specfile). > > "Sprog is a tool for working with data. It allows you to do all the things > those clever Unix geeks can do with their cryptic command lines but you can > now do it all with point-n-click and drag-n-drop. > > A Sprog machine has many similarities to a shell script. It is built from > small reusable parts (called gears) that are connected together to filter > and massage your data. Once you have built a machine, you can save it and > run it again and again to automatically perform repetitive tasks." > > It uses perl and Gtk2, amongst others. > New release: SRPM: http://www.perl.me.uk/downloads/Sprog/Sprog-0.13-1.src.rpm SPEC: http://www.perl.me.uk/downloads/Sprog/Sprog.spec > > Main Site: http://sprog.sourceforge.net/ > Article: http://www.perl.com/pub/a/2005/06/23/sprog.html > > Anyone care to review it? > > jpo? > > Thanks, > > Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From ghenry at suretecsystems.com Sun Jul 3 21:29:31 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 3 Jul 2005 22:29:31 +0100 Subject: New Package: perl-Gnome2-Canvas Message-ID: <200507032229.35182.ghenry@suretecsystems.com> Dear List, perl-Gnome2-Canvas for Sprog dependencies. SRPM: http://www.perl.me.uk/downloads/modules/perl-Gnome2-Canvas-1.002-1.src.rpm SPEC: http://www.perl.me.uk/downloads/modules/perl-Gnome2-Canvas.spec Anyone care to review it? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From igor.jagec at gmail.com Sun Jul 3 21:46:59 2005 From: igor.jagec at gmail.com (Igor Jagec) Date: Sun, 03 Jul 2005 23:46:59 +0200 Subject: Wish list Message-ID: <42C85CD3.9030400@gmail.com> Hi there! I'm having 2 wishes for the future Fedora releases. Just for starters :) 1. Better system-config-network tool. I can't set up a hexadecimal WEP key, and I follow all the instructions (putting 0x before the key). I can set up wep key only manually. It's not a problem to set it up manually, but that tool should be improved a little bit... 2. Make Gv4l program in Extras. It's a great program for capturing, very easy to use, easy to set up. The best I've ever seen on Linux, and I've seen them a lot (Mythtv, Zapping, Xawtv...) You should put some program for capturing because Tvtime does not have that feature. Thank you. -- Igor Jagec From ghenry at suretecsystems.com Sun Jul 3 21:42:37 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 3 Jul 2005 22:42:37 +0100 Subject: New Package: perl-Gtk2-GladeXML Message-ID: <200507032242.41750.ghenry@suretecsystems.com> Dear List, perl-Gtk2-GladeXML for Sprog dependencies. Summary: Perl interface to the 2.x series of the Gimp Toolkit library SRPM: http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML-1.005-1.src.rpm SPEC: http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML.spec Anyone care to review it? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Sun Jul 3 21:54:23 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Sun, 3 Jul 2005 17:54:23 -0400 (EDT) Subject: Trademarks In-Reply-To: <1120309593.27103.35.camel@localhost.localdomain> References: <1120303368.26373.30.camel@localhost.localdomain> <1120309593.27103.35.camel@localhost.localdomain> Message-ID: I would expect that our legal folks will expect that other trademarks be honored, just as we would expect our own trademarks to be honored. My $0.02: do your best to "do the right thing." Worst case scenario, someone yells at us and says, "hey, that's trademarked!" and we fix it. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Sat, 2 Jul 2005, Tom 'spot' Callaway wrote: > On Sat, 2005-07-02 at 14:22 +0300, Ville Skytt? wrote: > > Should one acknowledge trademarks somehow in all package summaries and > > descriptions in Extras? I think yes, but I don't see this mentioned in > > the Wiki anywhere, and there are many packages that would need to be > > updated wrt. this. > > > > For example, I'm committing an update to the kernel-module-thinkpad in a > > jiffy, with the following summary and description. Would this be > > ok/needed in all packages that refer to US/other trademarks, or is it > > possible to have a "blanket trademark acknowledgement" somewhere? Or > > something else? > > I suspect that what you've done is correct, but it should be run past RH > legal. Greg, what does legal want us to do with regards to other > people's trademarks? > > ~spot > -- > Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > From mpeters at mac.com Sun Jul 3 21:54:21 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 03 Jul 2005 14:54:21 -0700 Subject: Wish list In-Reply-To: <42C85CD3.9030400@gmail.com> References: <42C85CD3.9030400@gmail.com> Message-ID: <1120427661.2685.79.camel@locolhost.localdomain> On Sun, 2005-07-03 at 23:46 +0200, Igor Jagec wrote: > Hi there! > > I'm having 2 wishes for the future Fedora releases. Just for starters :) > > 1. Better system-config-network tool. I can't set up a hexadecimal WEP > key, and I follow all the instructions (putting 0x before the key). I > can set up wep key only manually. It's not a problem to set it up > manually, but that tool should be improved a little bit... This one should be directed at either bugzilla or the fedora user list. I haven't had a problem setting up wep myself - using a hex key. I did it though Network in System Settings (I don't use NetworkManager) so I'm guessing your issue is with something else - the fedora-user list can help identify that, and if needed, better identify how to file a bugzilla on it. From Christian.Iseli at licr.org Sun Jul 3 23:14:57 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 04 Jul 2005 01:14:57 +0200 Subject: ddrescue and dd_rescue In-Reply-To: Your message of "Sun, 03 Jul 2005 02:18:53 +0200." Message-ID: <200507032315.j63NF7pU013512@mx1.redhat.com> andreas at bawue.net said: > I could do that as well... > But I prefer single packages. In principle, I agree, but... > Furthermore: What to name the package? dd_rescue? ddrescue? dd_?rescue of course ;-) just kidding. I don't know... > And why is ddrescue included in dd_rescue or vice versa? I was just thinking of Joe User with a hosed disk. He goes to FE and tries to find a package to help the situation: there are two with almost the same name and the same purpose. Argh. So he does what you just did: test them. And basicaly finds out what you found out already: they are both useful in their own way. I still think a single package, along with explanations in the package description, is the least confusing. But I admit I can't help with the name. Maybe just use history: which one was first ? Cheers, Christian From buildsys at fedoraproject.org Mon Jul 4 01:14:42 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 3 Jul 2005 21:14:42 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050704011442.77BD6B243@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 21 anthy-6700-1.fc3 bazaar-1.4.2-1.fc3 cfengine-2.1.15-2.fc3 darcs-1.0.3-2.fc3 denyhosts-0.6.0-1.fc3 gai-0.5.10-3.fc3 gai-temp-0.1.1-2.fc3 gaim-otr-2.0.2-2.fc3 gnome-applet-sensors-1.0-1.fc3 gnome-theme-clearlooks-0.6.2-1 id3lib-3.8.3-11.fc3 libotr-2.0.2-7.fc3 lout-3.30-4.fc3 meld-0.9.6-0.fc3 mercurial-0.6-1.fc3 perl-MailTools-1.67-1.fc3 perl-Want-0.08-3.fc3 perl-Want-0.09-1.fc3 rblcheck-1.5-10.fc3 rbldnsd-0.995-4.fc3 xlockmore-5.18-3.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From andreas at bawue.net Mon Jul 4 01:18:42 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Mon, 4 Jul 2005 03:18:42 +0200 (CEST) Subject: Trademarks In-Reply-To: References: <1120303368.26373.30.camel@localhost.localdomain> <1120309593.27103.35.camel@localhost.localdomain> Message-ID: On Sun, 3 Jul 2005, Greg DeKoenigsberg wrote: > I would expect that our legal folks will expect that other trademarks be > honored, just as we would expect our own trademarks to be honored. Does honoring a trademark mean that it should be mentionend in the spec that it is a trademark? Or does it mean it's not misappropriated? bye, andreas From buildsys at fedoraproject.org Mon Jul 4 01:20:56 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 3 Jul 2005 21:20:56 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050704012056.3DA08B243@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 29 anthy-6700-1.fc4 bazaar-1.4.2-1.fc4 cfengine-2.1.15-2.fc4 darcs-1.0.3-2.fc4.1 denyhosts-0.6.0-1.fc4 diction-1.08-1.fc4 directfb-0.9.22-2.fc4 exim-4.52-1.fc4 gai-0.5.10-3.fc4 gai-temp-0.1.1-2.fc4 gaim-otr-2.0.2-2.fc4 gramps-2.0.4-1.fc4 id3lib-3.8.3-11.fc4 kinput2-v3.1-24.fc4 konversation-0.18-4.fc4 libassuan-0.6.10-1 libotr-2.0.2-7.fc4 libvisual-0.2.0-6.fc4 lout-3.30-4.fc4 mercurial-0.6-1.fc4 moodss-20.2-1.fc4 moomps-5.2-1.fc4 perl-MailTools-1.67-1.fc4 perl-Want-0.08-3.fc4 perl-Want-0.09-1.fc4 rbldnsd-0.995-4.fc4 rinetd-0.62-4.fc4 scim-anthy-0.5.0-1.fc4 xlockmore-5.18-3.fc4 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 Mon Jul 4 01:21:42 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 3 Jul 2005 21:21:42 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050704012142.8193BB243@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 35 NetworkManager-vpnc-0.2-2 aalib-1.4.0-0.rc5.5 anthy-6700-1 bazaar-1.4.2-1.fc5 cfengine-2.1.15-2.fc5 cone-0.64-5.fc5 darcs-1.0.3-2.fc5 diction-1.08-1.fc5 exim-4.52-1.fc5 fish-1.11.1-10.fc5 fping-2.4b2-5.fc5 gai-0.5.10-3.fc5 gcfilms-5.2-1.fc5 gnupg2-1.9.17-1.fc5 gramps-2.0.3-1.fc5 gramps-2.0.4-1.fc5 id3lib-3.8.3-11.fc5 kinput2-v3.1-25.fc5 libassuan-0.6.10-1.fc5 libkipi-0.1.1-1.2.fc5 libvisual-0.2.0-6.fc5 mercurial-0.6-1.fc5 moodss-20.2-1.fc5 moomps-5.2-1.fc5 most-4.10.1-1 perl-MailTools-1.67-1.fc5 perl-Want-0.08-3.fc5 perl-Want-0.09-1.fc5 pybliographer-1.2.6.2-4 python-bibtex-1.2.1-3 rblcheck-1.5-10.fc5 rbldnsd-0.995-4.fc5 rinetd-0.62-4.fc5 uim-0.4.6-5 xemacs-21.4.17-4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From mpeters at mac.com Mon Jul 4 02:05:41 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 03 Jul 2005 19:05:41 -0700 Subject: Trademarks In-Reply-To: References: <1120303368.26373.30.camel@localhost.localdomain> <1120309593.27103.35.camel@localhost.localdomain> Message-ID: <1120442741.2685.89.camel@locolhost.localdomain> On Mon, 2005-07-04 at 03:18 +0200, Andreas Thienemann wrote: > On Sun, 3 Jul 2005, Greg DeKoenigsberg wrote: > > > I would expect that our legal folks will expect that other trademarks be > > honored, just as we would expect our own trademarks to be honored. > Does honoring a trademark mean that it should be mentionend in the spec > that it is a trademark? > Or does it mean it's not misappropriated? I'm not a lawyer but I don't think it means it needs to be specified as tm or (r) or whatever in either the name or summary. I do think it should be noted in the description if the trademark is used in the description - and of course any documentation indicating trademark/ownership/etc should be packaged with %doc From luya at jpopmail.com Mon Jul 4 04:50:32 2005 From: luya at jpopmail.com (luya at jpopmail.com) Date: Sun, 03 Jul 2005 20:50:32 -0800 Subject: problem with rpmlib Message-ID: <20050704045032.DE23B2B2B86@ws5-7.us4.outblaze.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From ivazquez at ivazquez.net Mon Jul 4 05:03:37 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 01:03:37 -0400 Subject: problem with rpmlib In-Reply-To: <20050704045032.DE23B2B2B86@ws5-7.us4.outblaze.com> References: <20050704045032.DE23B2B2B86@ws5-7.us4.outblaze.com> Message-ID: <1120453417.15363.1.camel@ignacio.ignacio.lan> On Sun, 2005-07-03 at 20:50 -0800, luya at jpopmail.com wrote: > When building a package(gdesklets in this case) with fedora-rpmdevtools, I got a odd error related to rpmlib > > --- > Provides: ewmh.so.debug gtop.so.debug svg.so.debug systray.so.debug tiling.so.debug > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/gdesklets-0.35.1-1.rf-root > error: Installed (but unpackaged) file(s) found: > /usr/share/mime/aliases > /usr/share/mime/subclasses > > --- > > Does anyone know how to solve that issue on Fedora Core 4? This has *nothing* to do with rpmlib. It's strictly a spec file problem. Nor does it have anything to do with Fedora Extras, as that's a RPMForge package. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 caillon at redhat.com Mon Jul 4 06:09:32 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jul 2005 02:09:32 -0400 Subject: problem with rpmlib In-Reply-To: <20050704045032.DE23B2B2B86@ws5-7.us4.outblaze.com> References: <20050704045032.DE23B2B2B86@ws5-7.us4.outblaze.com> Message-ID: <42C8D29C.4080409@redhat.com> On 07/04/2005 12:50 AM, luya at jpopmail.com wrote: >When building a package(gdesklets in this case) with fedora-rpmdevtools, I got a odd error related to rpmlib > >--- >Provides: ewmh.so.debug gtop.so.debug svg.so.debug systray.so.debug tiling.so.debug >Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/gdesklets-0.35.1-1.rf-root >error: Installed (but unpackaged) file(s) found: > /usr/share/mime/aliases > /usr/share/mime/subclasses > >--- > >Does anyone know how to solve that issue on Fedora Core 4? > > > Make sure those files are listed in %files From mpeters at mac.com Mon Jul 4 06:49:42 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 03 Jul 2005 23:49:42 -0700 Subject: problem with rpmlib In-Reply-To: <42C8D29C.4080409@redhat.com> References: <20050704045032.DE23B2B2B86@ws5-7.us4.outblaze.com> <42C8D29C.4080409@redhat.com> Message-ID: <1120459782.2656.7.camel@locolhost.localdomain> On Mon, 2005-07-04 at 02:09 -0400, Christopher Aillon wrote: > On 07/04/2005 12:50 AM, luya at jpopmail.com wrote: > > >When building a package(gdesklets in this case) with fedora-rpmdevtools, I got a odd error related to rpmlib > > > >--- > >Provides: ewmh.so.debug gtop.so.debug svg.so.debug systray.so.debug tiling.so.debug > >Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > >Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/gdesklets-0.35.1-1.rf-root > >error: Installed (but unpackaged) file(s) found: > > /usr/share/mime/aliases > > /usr/share/mime/subclasses > > > >--- > > > >Does anyone know how to solve that issue on Fedora Core 4? > > > > > > > Make sure those files are listed in %files I suspect they are not suppose to be owned by the package, but rather, are suppose to be modified by the package - which means they should be in a %post script [mpeters at laptop ~]$ rpm -qf /usr/share/mime/aliases file /usr/share/mime/aliases is not owned by any package [mpeters at laptop ~]$ rpm -qf /usr/share/mime/subclasses file /usr/share/mime/subclasses is not owned by any package [mpeters at laptop ~]$ Either through a configure switch or patch, or even deletion during % install, the files should be removed from the buildroot. The makefile should be read so that the aliases and subclasses can be properly modified by %post script (which probably should involve a grep -c to make sure the entries aren't already there) There may be a tool designed specifically to deal with those files that may make things easier. I thought there was - desktop-mime-install or something like that. From j.w.r.degoede at hhs.nl Mon Jul 4 08:41:22 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jul 2005 10:41:22 +0200 Subject: mock build fails Message-ID: <42C8F632.2050707@hhs.nl> Hi I'm trying to use make mockbuild to sort out some build dependency issues, but I get: Non-zero return value 127 on executing /usr/sbin/mock-helper chroot /var/lib/mock//fedora-development-i386-core/root /sbin/runuser - root -c "/usr/sbin/useradd -u 0 -d /builddir mockbuild" This is running as root, I tried running as user before, that gave the same error. The file /sbin/runuser seems to be missing from /var/lib/mock//fedora-development-i386-core/root Any clues? Thanks, Hans From rc040203 at freenet.de Mon Jul 4 09:20:06 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 11:20:06 +0200 Subject: mock build fails In-Reply-To: <42C8F632.2050707@hhs.nl> References: <42C8F632.2050707@hhs.nl> Message-ID: <1120468806.6657.45.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 10:41 +0200, Hans de Goede wrote: > Hi I'm trying to use make mockbuild to sort out some build dependency > issues, but I get: > Non-zero return value 127 on executing /usr/sbin/mock-helper chroot > /var/lib/mock//fedora-development-i386-core/root /sbin/runuser - root -c > "/usr/sbin/useradd -u 0 -d /builddir mockbuild" > > This is running as root, I tried running as user before, that gave the > same error. > > The file /sbin/runuser seems to be missing from > /var/lib/mock//fedora-development-i386-core/root > > Any clues? Search bugzilla.redhat.com for "mock" (Include closed PR's into your search, some people close PRs even if they are unfixed). In a nutshell: The version in FE is doesn't support selinux, completely broken and non-functional, the version from the mock repository in Fedora's CVS also still has selinux probs, but is more or less functional. Ralf From j.w.r.degoede at hhs.nl Mon Jul 4 11:40:06 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jul 2005 13:40:06 +0200 Subject: Strange build errors (buildsys bug?) Message-ID: <42C92016.9010502@hhs.nl> Hi, I get the following errors when trying to build gnumeric for the devel tree: --- checking for gtk+-2.0 >= 2.4.0 libglade-2.0 >= 2.3.6 libgnomecanvas-2.0 >= 2.0.0 libgnomeprint-2.2 >= 2.5.2 libgnomeprintui-2.2 >= 2.5.2 libart-2.0 >= 2.3.11 ... Package libpng12 was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng12.pc' to the PKG_CONFIG_PATH environment variable Package 'libpng12', required by 'cairo', not found --- and: --- checking for libgnomedb >= 1.0.1 ... Package libpng12 was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng12.pc' to the PKG_CONFIG_PATH environment variable Package 'libpng12', required by 'cairo', not found --- and: --- ../../../src/workbook-control-gui.h:6:27: error: gtk/gtkwindow.h: No such file or directory ../../../src/workbook-control-gui.h:7:33: error: gtk/gtktoggleaction.h: No such file or directory ../../../src/cut-n-paste-code/goffice/utils/go-gradient.h:26:32: error: libart_lgpl/libart.h: No such file or directory ../../../src/cut-n-paste-code/goffice/utils/go-gradient.h:27:45: error: libart_lgpl/art_render_gradient.h: No such file or directory I first noticed the last (compile) errors, which are probably caused by the ./configure error. So I added BuildRequires for gtk2-devel and libart_lgpl-devel. But that didn't help. It seems that libpng-devel doesn't get installed in the buildroot, I could BuildRequire it, but: [hans at cq229 devel]$ rpm -q --requires gtk2-devel ... cairo-devel >= 0.5.1-1 ... and: [hans at cq229 devel]$ rpm -q --requires cairo-devel ... libpng-devel ... So it should get included automaticly right? Regards, Hans p.s. I've also tried debugging this with mock since I don't want to use the buildsys as a debugging tool (and to avoid release inflation), but mock is hopelessly broken, or so I've been told. I don't want to spend my time tinkering with a CVS build of mock. Can someone please upgrade the current mock package to CVS? From ivazquez at ivazquez.net Mon Jul 4 11:56:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 07:56:23 -0400 Subject: Strange build errors (buildsys bug?) In-Reply-To: <42C92016.9010502@hhs.nl> References: <42C92016.9010502@hhs.nl> Message-ID: <1120478183.15363.2.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 13:40 +0200, Hans de Goede wrote: > p.s. > > I've also tried debugging this with mock since I don't want to use the > buildsys as a debugging tool (and to avoid release inflation), but mock > is hopelessly broken, or so I've been told. I don't want to spend my > time tinkering with a CVS build of mock. Can someone please upgrade the > current mock package to CVS? Here's a package built from current CVS: http://fedora.ivazquez.net/files/mock-0.3-2.iva.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 j.w.r.degoede at hhs.nl Mon Jul 4 11:57:03 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jul 2005 13:57:03 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <1120478183.15363.2.camel@ignacio.ignacio.lan> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> Message-ID: <42C9240F.2090807@hhs.nl> Ignacio Vazquez-Abrams wrote: > On Mon, 2005-07-04 at 13:40 +0200, Hans de Goede wrote: > >>p.s. >> >>I've also tried debugging this with mock since I don't want to use the >>buildsys as a debugging tool (and to avoid release inflation), but mock >>is hopelessly broken, or so I've been told. I don't want to spend my >>time tinkering with a CVS build of mock. Can someone please upgrade the >>current mock package to CVS? > > > Here's a package built from current CVS: > > http://fedora.ivazquez.net/files/mock-0.3-2.iva.src.rpm > > Thanks, What about replacing the current (broken) fedora package with this? From ivazquez at ivazquez.net Mon Jul 4 12:27:53 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 08:27:53 -0400 Subject: Request for Review: binutils-mipsel Message-ID: <1120480073.15363.7.camel@ignacio.ignacio.lan> Yes, it's binutils for little-endian MIPS processors. This is the first package in the mipsel toolchain. It Requires binutils since it doesn't contain any translations (which would conflict with newer versions of binutils). http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Christian.Iseli at licr.org Mon Jul 4 12:43:52 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 04 Jul 2005 14:43:52 +0200 Subject: Reviews still needed In-Reply-To: Your message of "Sun, 03 Jul 2005 09:10:51 CDT." <1120399851.27103.53.camel@localhost.localdomain> Message-ID: <200507041243.j64ChqH9004846@ludwig-alpha.unil.ch> tcallawa at redhat.com said: > All of those issues are now resolved in CVS. Care to re-review (or approve)? > :) - rpmlint is silent (wow :) ok - name ok - spec name ok - packaging guidelines met ok - license ok - license matches actual license in package ok - license file in %doc ok - spec file in American English ok - spec file quite legible :) ok - source matches upstream md5 ok - builds, installs, runs, and uninstalls cleanly (on my FC3 test beast) ok - I think the BuildRequires can be simplified to: BuildRequires: kdelibs-devel, automake, autoconf, SDL-devel BuildRequires: mysql-devel, postgresql-devel, sqlite2-devel the reason is that kdelibs-devel automaticaly brings in all the other listed -devel packages (along with a few others). If not, I'd still like to hear optinions on wether to require XFree86-devel or xorg-x11-devel... - locale handling (none here) ok - shared libs handling ok - relocation (none) ok - files stuff: ok except README is listed twice in %doc - clean section ok - macro useage ok - package contains code ok - large documentation split ok - %doc is only doc ok - header files in -devel ok - .so in -devel not possible, so ok - -devel (and other) packages require main package ok - no .la files ok I'll trust you to use your best judgement for the BuildRequires thing, and to remove the extraneous README in the %doc line. Approved. Cheers, Christian From skvidal at phy.duke.edu Mon Jul 4 13:50:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Jul 2005 09:50:12 -0400 Subject: mock build fails In-Reply-To: <1120468806.6657.45.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> Message-ID: <1120485012.18966.1.camel@cutter> > Search bugzilla.redhat.com for "mock" (Include closed PR's into your > search, some people close PRs even if they are unfixed). > Passive aggressive much? Sheesh. I close the bug reports that are fixed in cvs, sure. Mostly b/c if it is fixed in cvs and I know it will eventually be out in a release then I don't have to chase down bugs after a release. -sv From skvidal at phy.duke.edu Mon Jul 4 13:51:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Jul 2005 09:51:23 -0400 Subject: Strange build errors (buildsys bug?) In-Reply-To: <42C9240F.2090807@hhs.nl> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> Message-ID: <1120485083.18966.3.camel@cutter> On Mon, 2005-07-04 at 13:57 +0200, Hans de Goede wrote: > Ignacio Vazquez-Abrams wrote: > > On Mon, 2005-07-04 at 13:40 +0200, Hans de Goede wrote: > > > >>p.s. > >> > >>I've also tried debugging this with mock since I don't want to use the > >>buildsys as a debugging tool (and to avoid release inflation), but mock > >>is hopelessly broken, or so I've been told. I don't want to spend my > >>time tinkering with a CVS build of mock. Can someone please upgrade the > >>current mock package to CVS? > > > > > > Here's a package built from current CVS: > > > > http://fedora.ivazquez.net/files/mock-0.3-2.iva.src.rpm > > > > > > Thanks, > > What about replacing the current (broken) fedora package with this? the current package isn't broken - just turn off selinux. There are other things in extras that do not work w/o selinux being off, either. -sv From rc040203 at freenet.de Mon Jul 4 14:07:35 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 16:07:35 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <1120485083.18966.3.camel@cutter> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> Message-ID: <1120486056.6657.57.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 09:51 -0400, seth vidal wrote: > On Mon, 2005-07-04 at 13:57 +0200, Hans de Goede wrote: > > Ignacio Vazquez-Abrams wrote: > > > On Mon, 2005-07-04 at 13:40 +0200, Hans de Goede wrote: > > > > > >>p.s. > > >> > > >>I've also tried debugging this with mock since I don't want to use the > > >>buildsys as a debugging tool (and to avoid release inflation), but mock > > >>is hopelessly broken, or so I've been told. I don't want to spend my > > >>time tinkering with a CVS build of mock. Can someone please upgrade the > > >>current mock package to CVS? > > > > > > > > > Here's a package built from current CVS: > > > > > > http://fedora.ivazquez.net/files/mock-0.3-2.iva.src.rpm > > > > > > > > > > Thanks, > > > > What about replacing the current (broken) fedora package with this? > > the current package isn't broken I disagree: # rpm -qlp mock-0.3-2.fc4.i386.rpm /etc/mock /etc/mock/default.cfg /etc/mock/fedora-3-i386-core.cfg /etc/mock/fedora-3-x86_64-core.cfg /etc/mock/fedora-development-i386-core.cfg /etc/mock/fedora-development-ppc-core.cfg /etc/mock/fedora-development-x86_64-core.cfg /usr/bin/mock /usr/sbin/mock-helper /usr/share/doc/mock-0.3 /usr/share/doc/mock-0.3/ChangeLog /usr/share/doc/mock-0.3/README /var/lib/mock The package even lacks the fe4-config files. > - just turn off selinux. There are > other things in extras that do not work w/o selinux being off, either. True, everbody know selinux is hardly usable ... Ralf From tcallawa at redhat.com Mon Jul 4 14:47:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Jul 2005 09:47:53 -0500 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120480073.15363.7.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> Message-ID: <1120488473.27103.88.camel@localhost.localdomain> On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > Yes, it's binutils for little-endian MIPS processors. This is the first > package in the mipsel toolchain. Is this meant to be run through a cross-compiler? Its a little early for me, but I would think that you'd want a piece of the mipsel toolchain to be compiled for mipsel. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Mon Jul 4 14:50:53 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 16:50:53 +0200 Subject: mock build fails In-Reply-To: <1120485012.18966.1.camel@cutter> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> Message-ID: <1120488653.6657.64.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 09:50 -0400, seth vidal wrote: > > Search bugzilla.redhat.com for "mock" (Include closed PR's into your > > search, some people close PRs even if they are unfixed). > > > > Passive aggressive much? Sheesh. I close the bug reports that are fixed > in cvs, sure. Mostly b/c if it is fixed in cvs and I know it will > eventually be out in a release then I don't have to chase down bugs > after a release. you are missing one essential point: FE PRs in bugzilla.redhat.com refer to FE not to your private sources. So a PR remains unfixed, unless it is fixed by a package in FE. Closing PRs in bugzilla, doesn't help end users which are stuck with a problem and are eagerly waiting for you to provide a fix, and lets appear you as a jerk to them. Ralf From ed at eh3.com Mon Jul 4 14:52:34 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 04 Jul 2005 10:52:34 -0400 Subject: Request for Approval: hdf5 In-Reply-To: <42C567E0.3040708@cora.nwra.com> References: <1119989530.3226.7.camel@localhost.localdomain> <1120002949.2513.7.camel@localhost.localdomain> <1120089574.2513.158.camel@localhost.localdomain> <42C41DA9.5060609@cora.nwra.com> <42C567E0.3040708@cora.nwra.com> Message-ID: <1120488754.10305.8.camel@ernie> On Fri, 2005-07-01 at 09:57 -0600, Orion Poplawski wrote: > Orion Poplawski wrote: > > It compiles and tests fine on FC3, so perhaps it's a gcc 4.0.0 issue? > > Not sure how easy it would be to cook up a small example that I could > > send to the gcc folks. > > > > Fixed the bug in the hdf5 code so it compiles and checks clean now. > Will be submitting upstream. > > Latest versions: > > http://www.cora.nwra.com/~orion/fedora/hdf5-1.6.4-3.src.rpm > http://www.cora.nwra.com/~orion/fedora/hdf5.spec > > Please review (and/or approve) Hi Orion, Good: - source matches upstream - builds, installs, and seems to work correctly on FC-4 - "make check" in the spec reported all tests as either PASSED or -SKIP- which looks good - *.la files have been cleaned up - can't find any other problems! Perhaps (?) needs work: - rpmlint hdf5: - about a dozen %doc files have execute permissions set when they should probably be just 644 - there are many zero-length Dependencies files in the docs that rpmlint complains about but looking at the included Makefiles it seems that they are actually used and parsed and just need to be empty - a few end-of-line encoding warnings on %doc files but they're HTML so would anyone care...? - rpmlint hdf5-devel: W: hdf5-devel no-provides hdf-devel W: hdf5-devel summary-not-capitalized hdf5 development files Please fix the permissions and take a look at the warnings. Since its all just minor stuff, I'll send an approved message soon. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From rc040203 at freenet.de Mon Jul 4 14:55:48 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 16:55:48 +0200 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120480073.15363.7.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> Message-ID: <1120488948.6657.68.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > Yes, it's binutils for little-endian MIPS processors. This is the first > package in the mipsel toolchain. > > It Requires binutils since it doesn't contain any translations (which > would conflict with newer versions of binutils). It's worse. For cross toolchains, you must --disable-nls or require exactly the same version of nls-files for the native and the cross toolchain. I strongly recommend disabling nls to avoid getting swamped dependencies. > http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec > http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src.rpm Besides this, the spec basically looks OK to me. Ralf From tcallawa at redhat.com Mon Jul 4 15:00:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Jul 2005 10:00:01 -0500 Subject: Reviews still needed In-Reply-To: References: <200507011419.j61EJgfd021141@ludwig-alpha.unil.ch> <1120228972.8990.172.camel@localhost.localdomain> Message-ID: <1120489201.27103.93.camel@localhost.localdomain> On Fri, 2005-07-01 at 11:32 -0400, Chris Ricker wrote: > On Fri, 1 Jul 2005, Tom 'spot' Callaway wrote: > > > Policy changed at FUDCon II. Basically, it is now ok for packages to not > > build on some architectures, as long as its documented that they do not. > > Anything else of note change? Lots of discussion on what constitutes a review, molded into: http://fedoraproject.org/wiki/PackageReviewGuidelines We had some discussion about code vs content, which is documented here: http://www.fedoraproject.org/wiki/PackagingGuidelines#CodeVsContent ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Mon Jul 4 15:04:59 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 11:04:59 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120488473.27103.88.camel@localhost.localdomain> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120488473.27103.88.camel@localhost.localdomain> Message-ID: <1120489499.15363.13.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 09:47 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > > Yes, it's binutils for little-endian MIPS processors. This is the first > > package in the mipsel toolchain. > > Is this meant to be run through a cross-compiler? Its a little early for > me, but I would think that you'd want a piece of the mipsel toolchain to > be compiled for mipsel. No, it's meant to run on i386, ppc, etc. The target system is mipsel-linux, but the host system is i386-linux, powerpc-linux, etc. It's the first step in getting a cross compiler running. The part that needs to be compiled for mipsel is glibc, and I haven't gotten there just yet (still working on a minimal mipsel-linux-gcc). -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ivazquez at ivazquez.net Mon Jul 4 15:35:22 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 11:35:22 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120488948.6657.68.camel@mccallum.corsepiu.local> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120488948.6657.68.camel@mccallum.corsepiu.local> Message-ID: <1120491323.15363.14.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 16:55 +0200, Ralf Corsepius wrote: > On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > > Yes, it's binutils for little-endian MIPS processors. This is the first > > package in the mipsel toolchain. > > > > It Requires binutils since it doesn't contain any translations (which > > would conflict with newer versions of binutils). > > It's worse. For cross toolchains, you must --disable-nls or require > exactly the same version of nls-files for the native and the cross > toolchain. > > I strongly recommend disabling nls to avoid getting swamped > dependencies. Will I still need to Require binutils if I use --disable-nls? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 fedora at camperquake.de Mon Jul 4 15:45:35 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 4 Jul 2005 17:45:35 +0200 Subject: Request for Review: libevent In-Reply-To: <42C5F4C0.2000700@di.uminho.pt> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> <42C5F4C0.2000700@di.uminho.pt> Message-ID: <20050704174535.269e5206@nausicaa.camperquake.de> Hi. Jos? Pedro Oliveira wrote: > Everything else looks good. Feel free to import it into the > Extras' CVS. Thanks, package is in CVS now. -- The magic words are `squeamish ossifrage'. From tcallawa at redhat.com Mon Jul 4 16:01:15 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Jul 2005 11:01:15 -0500 Subject: Request for Review: R-hdf5 Message-ID: <1120492875.30349.5.camel@localhost.localdomain> Since hdf5 is now approved, it only makes sense to get R-hdf5 in as well. R-hdf5 provides an interface to the NCSA HDF5 library for R. Like most R addon packages, its small and simple. SRPM: http://www.auroralinux.org/people/spot/review/R-hdf5-1.6.0-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/R-hdf5.spec Thanks in advance, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Mon Jul 4 16:09:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 18:09:26 +0200 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120491323.15363.14.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120488948.6657.68.camel@mccallum.corsepiu.local> <1120491323.15363.14.camel@ignacio.ignacio.lan> Message-ID: <1120493367.6657.80.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 11:35 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-07-04 at 16:55 +0200, Ralf Corsepius wrote: > > On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > > > Yes, it's binutils for little-endian MIPS processors. This is the first > > > package in the mipsel toolchain. > > > > > > It Requires binutils since it doesn't contain any translations (which > > > would conflict with newer versions of binutils). > > > > It's worse. For cross toolchains, you must --disable-nls or require > > exactly the same version of nls-files for the native and the cross > > toolchain. > > > > I strongly recommend disabling nls to avoid getting swamped > > dependencies. > > Will I still need to Require binutils if I use --disable-nls? It depends. As far as nls is concerned, no. But there exist other files being shared between binutils and cross-binutils, e.g. the info files. Unlike the actual tools, these don't get canonicalized for cross-toolchains and therefore conflict with the native info-files. (The binutils' manpages are canonicalized and do not conflict). BTW: I'd recommend not to use "mipssel-linux" as target tuple, but to use a fully expanded target tuple, matching the target OS you actually are addressing, e.g. mipssel-redhat-linux. Ralf From dwmw2 at infradead.org Mon Jul 4 16:14:57 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 Jul 2005 17:14:57 +0100 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120480073.15363.7.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> Message-ID: <1120493698.19467.76.camel@hades.cambridge.redhat.com> On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > Yes, it's binutils for little-endian MIPS processors. This is the > first package in the mipsel toolchain. Can we not have binutils-multi instead? -- dwmw2 From dwmw2 at infradead.org Mon Jul 4 16:16:30 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 Jul 2005 17:16:30 +0100 Subject: Trademarks In-Reply-To: References: <1120303368.26373.30.camel@localhost.localdomain> Message-ID: <1120493791.19467.79.camel@hades.cambridge.redhat.com> On Sat, 2005-07-02 at 09:33 -0500, Ian Pilcher wrote: > Ville Skytt? wrote: > > Summary: Supplemental kernel modules for ThinkPad? laptop computers > > I would recommend sticking to straight ASCII, maybe ThinkPad(R)? Why? I think we all ought to be able to handle UTF-8 now. -- dwmw2 From j.w.r.degoede at hhs.nl Mon Jul 4 16:25:39 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jul 2005 18:25:39 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <1120485083.18966.3.camel@cutter> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> Message-ID: <42C96303.9050900@hhs.nl> Enough discussion what about the real subject of the mail, not the ps. The strange failing of gnumeric to build appearantly due to a missing BuildReq for libpng-devel, which should not be nescesarry since other Builddeps depend on libpng-devel Thanks, Hans From ivazquez at ivazquez.net Mon Jul 4 16:28:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 12:28:42 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120493367.6657.80.camel@mccallum.corsepiu.local> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120488948.6657.68.camel@mccallum.corsepiu.local> <1120491323.15363.14.camel@ignacio.ignacio.lan> <1120493367.6657.80.camel@mccallum.corsepiu.local> Message-ID: <1120494522.15363.19.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 18:09 +0200, Ralf Corsepius wrote: > On Mon, 2005-07-04 at 11:35 -0400, Ignacio Vazquez-Abrams wrote: > > Will I still need to Require binutils if I use --disable-nls? > > It depends. As far as nls is concerned, no. > > But there exist other files being shared between binutils and > cross-binutils, e.g. the info files. Unlike the actual tools, these > don't get canonicalized for cross-toolchains and therefore conflict with > the native info-files. (The binutils' manpages are canonicalized and do > not conflict). Yes, I saw that bit. I'm going to ahead and make the executive decision that .info files are of low priority since they already exist in the binutils package, and I'm going to drop the "Requires: binutils". > BTW: I'd recommend not to use "mipssel-linux" as target tuple, but to > use a fully expanded target tuple, matching the target OS you actually > are addressing, e.g. mipssel-redhat-linux. TBH I don't really *have* a target OS per se; I'm building the toolchain in order to get Linux (most likely LFS) running on a HPC. But if it helps create a mipsel branch for Rawhide then I'll go ahead and change it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ivazquez at ivazquez.net Mon Jul 4 16:34:08 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Jul 2005 12:34:08 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120493698.19467.76.camel@hades.cambridge.redhat.com> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120493698.19467.76.camel@hades.cambridge.redhat.com> Message-ID: <1120494848.15363.22.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 17:14 +0100, David Woodhouse wrote: > On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > > Yes, it's binutils for little-endian MIPS processors. This is the > > first package in the mipsel toolchain. > > Can we not have binutils-multi instead? While I'm not totally against that idea, how do we define which targets go in it? All of them? Only the "cool" ones? And what about binutils-powerpc.i386? How is that handled when building on ppc instead? I can easily see the spec file becoming a maintenance nightmare. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 fedora at camperquake.de Mon Jul 4 16:31:57 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 4 Jul 2005 18:31:57 +0200 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120493698.19467.76.camel@hades.cambridge.redhat.com> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120493698.19467.76.camel@hades.cambridge.redhat.com> Message-ID: <20050704183157.22abfcc5@nausicaa.camperquake.de> Hi. David Woodhouse wrote: > Can we not have binutils-multi instead? And summarize all crosscompiling packages in there? What would be the use? -- Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld From ed at eh3.com Mon Jul 4 16:41:18 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 04 Jul 2005 12:41:18 -0400 Subject: Request for Review: R-hdf5 In-Reply-To: <1120492875.30349.5.camel@localhost.localdomain> References: <1120492875.30349.5.camel@localhost.localdomain> Message-ID: <1120495278.10305.50.camel@ernie> On Mon, 2005-07-04 at 11:01 -0500, Tom 'spot' Callaway wrote: > Since hdf5 is now approved, it only makes sense to get R-hdf5 in as > well. > > R-hdf5 provides an interface to the NCSA HDF5 library for R. > > Like most R addon packages, its small and simple. > > SRPM: > http://www.auroralinux.org/people/spot/review/R-hdf5-1.6.0-1.src.rpm > SPEC: http://www.auroralinux.org/people/spot/review/R-hdf5.spec Hi Spot, Heres the review: - rpmlint reports: W: R-hdf5 invalid-license GPL version 2 or later W: R-hdf5 dangerous-command-in-%post perl W: R-hdf5 dangerous-command-in-%postun perl - naming OK - license OK - source matches upstream - builds & installs on FC4 - BuildRequires seems OK - dir ownership looks OK - perms all look OK - %clean is OK Since I don't see any blockers, I'll send an approved in a few minutes. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From skvidal at phy.duke.edu Mon Jul 4 17:12:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Jul 2005 13:12:25 -0400 Subject: mock build fails In-Reply-To: <1120488653.6657.64.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> Message-ID: <1120497145.18966.20.camel@cutter> On Mon, 2005-07-04 at 16:50 +0200, Ralf Corsepius wrote: > On Mon, 2005-07-04 at 09:50 -0400, seth vidal wrote: > > > Search bugzilla.redhat.com for "mock" (Include closed PR's into your > > > search, some people close PRs even if they are unfixed). > > > > > > > Passive aggressive much? Sheesh. I close the bug reports that are fixed > > in cvs, sure. Mostly b/c if it is fixed in cvs and I know it will > > eventually be out in a release then I don't have to chase down bugs > > after a release. > you are missing one essential point: > > FE PRs in bugzilla.redhat.com refer to FE not to your private sources. > So a PR remains unfixed, unless it is fixed by a package in FE. my private sources? It's fixed in fedora cvs, which is where mock is maintained. > Closing PRs in bugzilla, doesn't help end users which are stuck with a > problem and are eagerly waiting for you to provide a fix, and lets > appear you as a jerk to them. It's odd, I know folks at rh who close bugs and RFEs in red hat-developed programs when they check in the fix to CVS, too. All it means is: "This bug is fixed and will be released eventually" -sv From skvidal at phy.duke.edu Mon Jul 4 17:23:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Jul 2005 13:23:19 -0400 Subject: Trademarks In-Reply-To: <1120493791.19467.79.camel@hades.cambridge.redhat.com> References: <1120303368.26373.30.camel@localhost.localdomain> <1120493791.19467.79.camel@hades.cambridge.redhat.com> Message-ID: <1120497799.18966.24.camel@cutter> On Mon, 2005-07-04 at 17:16 +0100, David Woodhouse wrote: > On Sat, 2005-07-02 at 09:33 -0500, Ian Pilcher wrote: > > Ville Skytt? wrote: > > > Summary: Supplemental kernel modules for ThinkPad? laptop computers > > > > I would recommend sticking to straight ASCII, maybe ThinkPad(R)? > > Why? I think we all ought to be able to handle UTF-8 now. as long as folks write the symbol in utf-8 and not in some other odd encoding. :) -sv From fedora at camperquake.de Mon Jul 4 17:27:20 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 4 Jul 2005 19:27:20 +0200 Subject: Trademarks In-Reply-To: <1120497799.18966.24.camel@cutter> References: <1120303368.26373.30.camel@localhost.localdomain> <1120493791.19467.79.camel@hades.cambridge.redhat.com> <1120497799.18966.24.camel@cutter> Message-ID: <20050704192720.187b1e19@nausicaa.camperquake.de> Hi. seth vidal wrote: > as long as folks write the symbol in utf-8 and not in some other odd > encoding. :) That would be U+00AE. -- "I propose we leave math to the machines and go play outside." -- Calvin From i.pilcher at comcast.net Mon Jul 4 18:04:22 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 04 Jul 2005 13:04:22 -0500 Subject: Trademarks In-Reply-To: <1120493791.19467.79.camel@hades.cambridge.redhat.com> References: <1120303368.26373.30.camel@localhost.localdomain> <1120493791.19467.79.camel@hades.cambridge.redhat.com> Message-ID: David Woodhouse wrote: > Why? I think we all ought to be able to handle UTF-8 now. I'm pretty sure that there are some locales that still don't use UTF-8 by default. Even if that's not the case, there's certainly nothing preventing people from using other encodings. Folks that work with a lot of data in older encodings may well do this. Until the day comes that there's a hard Unicode-only policy, it seems to me that the benefits of sticking to ASCII-only in package summaries and descriptions outweighs the benefits. (Alternatively, RPM could be enhanced to store everything in UTF-8 and convert to other encodings.) -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From bugs.michael at gmx.net Mon Jul 4 18:23:04 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jul 2005 20:23:04 +0200 Subject: mock build fails In-Reply-To: <1120485012.18966.1.camel@cutter> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> Message-ID: <20050704202304.6a257f7b.bugs.michael@gmx.net> On Mon, 04 Jul 2005 09:50:12 -0400, seth vidal wrote: > > > Search bugzilla.redhat.com for "mock" (Include closed PR's into your > > search, some people close PRs even if they are unfixed). > > > > Passive aggressive much? Sheesh. I close the bug reports that are fixed > in cvs, sure. Mostly b/c if it is fixed in cvs and I know it will > eventually be out in a release then I don't have to chase down bugs > after a release. And everyone else, who runs into the same bug meanwhile, must chase down _closed_ (!) bugs and then wonder why the offered packages are still affected by the bug. A user, who reports a broken package, wants a fixed package that works. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1411_FC5 loadavg: 1.40 1.20 1.26 From luya at jpopmail.com Mon Jul 4 18:23:13 2005 From: luya at jpopmail.com (luya at jpopmail.com) Date: Mon, 04 Jul 2005 10:23:13 -0800 Subject: problem with rpmlib Message-ID: <20050704182313.2BF8123D05@ws5-3.us4.outblaze.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gdesklets.spec Type: application/octet-stream Size: 2537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gdesklets-display-thumbnail.schemas Type: application/octet-stream Size: 1005 bytes Desc: not available URL: From toniw at iki.fi Mon Jul 4 18:26:43 2005 From: toniw at iki.fi (Toni Willberg) Date: Mon, 04 Jul 2005 21:26:43 +0300 Subject: anyone working on Request Tracker, rt3? In-Reply-To: <1111066707.5463.31.camel@localhost.localdomain> References: <1111066707.5463.31.camel@localhost.localdomain> Message-ID: <1120501604.5533.6.camel@ihaa.home.willberg.fi> On Thu, 2005-03-17 at 15:38 +0200, Toni Willberg wrote: > Hi. > > Is someone actively working on to get rt3 (http://bestpractical.com/rt/) > into Extras? > > I recall there was someone working on it for fedora.us, but I lost track > of it. > > The tricky part of rt3 is that it depends on some 50 Perl modules, which > of not all are already in Core or Extras. > > If I find time, I'm willing to help if someone is already working on > this. Unfortunately I don't have time to manage all of it by myself. > > - Toni Ok, it's time to resume our RT packaging efforts as I've volunteered to install RT to GNOME.org servers (which are running RHEL btw.) Now if there's someone interested in the issue and having some spare time during July please let me know. I'm hanging on #fedora-developers with nickname "Toni". Yours, Toni From wart at kobold.org Mon Jul 4 19:40:08 2005 From: wart at kobold.org (Wart) Date: Mon, 04 Jul 2005 12:40:08 -0700 Subject: New package: tcllib Message-ID: <42C99098.8070708@kobold.org> Submitting this new package for review: %description Tcllib, the Tcl Standard Library is a collection of Tcl packages that provide utility functions useful to a large collection of Tcl programmers. The home web site for this code is http://tcllib.sourceforge.net/. At this web site, you will find mailing lists, web forums, databases for bug reports and feature requests, the CVS repository (browsable on the web, or read-only accessible via CVS ), and more. Note: also grab source tarball for more documentation, examples, ... http://www.kobold.org/~wart/fedora/MD5SUM.asc http://www.kobold.org/~wart/fedora/tcllib.spec http://www.kobold.org/~wart/fedora/tcllib-1.7-2.src.rpm Builds fine in mock. The only warnings from rpmlint look similar to: E: tcllib non-executable-script /usr/share/tcl8.4/tcllib-1.7/pop3/clnt.tcl 0644 E: tcllib script-without-shellbang /usr/share/tcl8.4/tcllib-1.7/math/fourier.tcl ...which should be harmless because these are script libraries, not standalone executable scripts. Credits go to Jean-Luc Fontaine for the initial spec file that I modified only slightly for Fedora Extras. I'm still waiting for a sponsor for CVS access for tclhttpd, and now this package. --Mike From g.hollestelle at gmail.com Mon Jul 4 19:58:12 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Mon, 4 Jul 2005 21:58:12 +0200 Subject: New Package: gcm (GNOME Clipboard Manager) In-Reply-To: <42C336C2.9020602@gmail.com> References: <42C336C2.9020602@gmail.com> Message-ID: <95da2d2905070412584c36795e@mail.gmail.com> On 6/30/05, P229 wrote: > GNOME Clipboard Manager facilitates management of clipboard contents > and, of particular importance, allows access to clipboard contents even > after the clip source is closed. > > SRPM, spec file, etc.: https://amdg.dyndns.org/~p229/index.html Hi, I'm not really an expert in these reviews, but I'll have a try at it as I would like to see gcm included (or some other way to preserve the clipboard). Good: - Source matches upstream - License is OK (GPL) Not so good: - rpmlint: W: gcm non-standard-group X11/Utilities W: gcm no-version-in-last-changelog W: gcm conffile-without-noreplace-flag /etc/gconf/schemas/gcmapplet.schemas E: gcm library-without-ldconfig-postin /usr/lib/librtftohtml.so.0.2.0 E: gcm library-without-ldconfig-postun /usr/lib/librtftohtml.so.0.2.0 E: gcm library-without-ldconfig-postin /usr/lib/libgcm.so.0.2.0 E: gcm library-without-ldconfig-postun /usr/lib/libgcm.so.0.2.0 E: gcm zero-length /usr/share/doc/gcm-2.0.4/NEWS W: gcm non-standard-dir-in-usr libexec - Missing build requires: gnome-panel-devel - Why the if ! -x configure test in %build? I would just assume the upstream tarball has a configure script, so just get rid of the ! -x configure test. - There are a lot of installed but unpackaged .h .la and .pc files, maybe consider making a gcm-devel subpackage and putting these files there? - There are plugins installed but unpackaged - There are a lot of other unpackaged files, which are being worked around by using: %define _unpackaged_files_terminate_build 0 %define _missing_doc_files_terminate_build 0 I think it would be better to remove the unwanted files than to do it like this. In order to resolve the last issue, see for example Dries' package of gcm: http://dries.ulyssis.org/rpm/packages/gcm/gcm-spec.html Greets, Gijs From igor.jagec at gmail.com Mon Jul 4 20:20:01 2005 From: igor.jagec at gmail.com (Igor Jagec) Date: Mon, 04 Jul 2005 22:20:01 +0200 Subject: Wish list In-Reply-To: <1120427661.2685.79.camel@locolhost.localdomain> References: <42C85CD3.9030400@gmail.com> <1120427661.2685.79.camel@locolhost.localdomain> Message-ID: <42C999F1.5070309@gmail.com> Michael A. Peters wrote: >>1. Better system-config-network tool. I can't set up a hexadecimal WEP >> key, and I follow all the instructions (putting 0x before the key). I >> can set up wep key only manually. It's not a problem to set it up >> manually, but that tool should be improved a little bit... > This one should be directed at either bugzilla or the fedora user list. Ok, thanks. I'll try to find that one. > I haven't had a problem setting up wep myself - using a hex key. Well, I have. MSI PC54G2 with Ralink RT2500 chipset. Thanks, I'll try to find those mailing lists. -- Igor Jagec From rc040203 at freenet.de Mon Jul 4 21:29:45 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 23:29:45 +0200 Subject: mock build fails In-Reply-To: <1120497145.18966.20.camel@cutter> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> Message-ID: <1120512586.6657.106.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 13:12 -0400, seth vidal wrote: > On Mon, 2005-07-04 at 16:50 +0200, Ralf Corsepius wrote: > > On Mon, 2005-07-04 at 09:50 -0400, seth vidal wrote: > > Closing PRs in bugzilla, doesn't help end users which are stuck with a > > problem and are eagerly waiting for you to provide a fix, and lets > > appear you as a jerk to them. > > It's odd, I know folks at rh who close bugs and RFEs in red > hat-developed programs when they check in the fix to CVS, too. FE doesn't have any control over what they do. RH has the freedom to apply whatever development policy they prefer, no matter what users think about it or how harmful it might be to RH. > All it means is: "This bug is fixed and will be released eventually" The same way yum now supports "--download-only" and the same way yelp meanwhile supports reading man pages and info files? Ralf From skvidal at phy.duke.edu Mon Jul 4 21:34:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Jul 2005 17:34:40 -0400 Subject: mock build fails In-Reply-To: <1120512586.6657.106.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> Message-ID: <1120512880.18966.46.camel@cutter> > FE doesn't have any control over what they do. RH has the freedom to > apply whatever development policy they prefer, no matter what users > think about it or how harmful it might be to RH. > > > All it means is: "This bug is fixed and will be released eventually" > The same way yum now supports "--download-only" and the same way yelp > meanwhile supports reading man pages and info files? > what are you talking about? yum dropped support for download-only in the 2.1.X branch and it was 'brought back' via yum-utils. nothing more. I don't know how I pissed in your cornflakes but you'd get a lot further with your requests of me if you didn't make such passive-aggressive comments as in your first post and then come along later and call me a jerk. It's not helpful nor conducive to a productive environment. -sv From rc040203 at freenet.de Mon Jul 4 21:57:39 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jul 2005 23:57:39 +0200 Subject: mock build fails In-Reply-To: <1120512880.18966.46.camel@cutter> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> <1120512880.18966.46.camel@cutter> Message-ID: <1120514259.6657.117.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 17:34 -0400, seth vidal wrote: > > FE doesn't have any control over what they do. RH has the freedom to > > apply whatever development policy they prefer, no matter what users > > think about it or how harmful it might be to RH. > > > > > All it means is: "This bug is fixed and will be released eventually" > > The same way yum now supports "--download-only" and the same way yelp > > meanwhile supports reading man pages and info files? > > > > what are you talking about? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109002#c1 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133052#c2 > yum dropped support for download-only in the > 2.1.X branch and it was 'brought back' via yum-utils. > > nothing more. > I don't know how I pissed in your cornflakes Then I'll tell you: You are shipping a broken package at full conciousness about its brokenness and refuse to withdraw or fix this package. Conversely, you continue to tell users where to grab the sources and to rebuild the package themselves. > It's not helpful nor conducive to a productive environment. YOU are this package's developer and maintainer. Ralf From skvidal at phy.duke.edu Mon Jul 4 22:16:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Jul 2005 18:16:07 -0400 Subject: mock build fails In-Reply-To: <1120514259.6657.117.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> <1120512880.18966.46.camel@cutter> <1120514259.6657.117.camel@mccallum.corsepiu.local> Message-ID: <1120515367.18966.50.camel@cutter> On Mon, 2005-07-04 at 23:57 +0200, Ralf Corsepius wrote: > On Mon, 2005-07-04 at 17:34 -0400, seth vidal wrote: > > > FE doesn't have any control over what they do. RH has the freedom to > > > apply whatever development policy they prefer, no matter what users > > > think about it or how harmful it might be to RH. > > > > > > > All it means is: "This bug is fixed and will be released eventually" > > > The same way yum now supports "--download-only" and the same way yelp > > > meanwhile supports reading man pages and info files? > > > > > > > what are you talking about? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109002#c1 right - it's closed - it is an upstream issue - not for that bugzilla. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133052#c2 it is a duplicate of something upstream. How am I wrong in either of those cases? > Then I'll tell you: > > You are shipping a broken package at full conciousness about its > brokenness and refuse to withdraw or fix this package. Conversely, you > continue to tell users where to grab the sources and to rebuild the > package themselves. > umm. I tell users how to make mock work on their systems. If they asked me how to make lighttpd or dhcpd work I'd tell them to turn off selinux, too. > > It's not helpful nor conducive to a productive environment. > YOU are this package's developer and maintainer. So it's okay for you to call a developer and maintainer a jerk? It's appropriate and helpful? You really take the cake. -sv From mwiktowy at gmx.net Mon Jul 4 22:38:28 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Mon, 04 Jul 2005 18:38:28 -0400 Subject: mock build fails In-Reply-To: <1120514259.6657.117.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> <1120512880.18966.46.camel@cutter> <1120514259.6657.117.camel@mccallum.corsepiu.local> Message-ID: <42C9BA64.1000605@gmx.net> Ralf Corsepius wrote: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109002#c1 > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133052#c2 > >You are shipping a broken package at full conciousness about its >brokenness and refuse to withdraw or fix this package. Conversely, you >continue to tell users where to grab the sources and to rebuild the >package themselves. > > >YOU are this package's developer and maintainer. > >Ralf > > Oh the draaaama! I think those bugs quite adequately explain what is going on and where to find and track progress. Personally, I appreciate a more conservative approach to updating yum. A truly broken updater is one of the things that can totally break your system. Keeping non-critical bugs for the sake of not introducing critical bugs by pushing out a version too early is wise. The lack of --download-only functionality is a non-critical bug for me and I suspect many people. If it is truly critical for you than a work-around might be to whip up a script that takes the output of "yum list updates" and, with reference to the files in /etc/yum/repo.d/ or your favourite mirror site, feeds it to wget ... or just get the upstream cvs, build it yourself and deal with the other potential problems that most are happy to avoid. Please do not force your priorities and haste on everyone else. /Mike From rc040203 at freenet.de Mon Jul 4 22:41:58 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jul 2005 00:41:58 +0200 Subject: Re: mock build fails In-Reply-To: <1120515367.18966.50.camel@cutter> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> <1120512880.18966.46.camel@cutter> <1120514259.6657.117.camel@mccallum.corsepiu.local> <1120515367.18966.50.camel@cutter> Message-ID: <1120516918.6657.139.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 18:16 -0400, seth vidal wrote: > So it's okay for you to call a developer and maintainer a jerk? Did I say you are a jerk? Let me cite what I wrote: "Closing PRs in bugzilla, doesn't help end users which are stuck with a problem and are eagerly waiting for you to provide a fix, and lets appear you as a jerk to them." > So it's okay for you to call a developer and maintainer a jerk? Read again what I wrote. I ment to say "end users will consider maintainers closing PRs without proving fixes/fixed packages to be jerks." You closed PRs without proving fixes and continue to ship broken packages. End users will draw their conclusions. > It's appropriate and helpful? Yes, think about it. Ralf From mwiktowy at gmx.net Mon Jul 4 23:52:48 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Mon, 04 Jul 2005 19:52:48 -0400 Subject: Re: mock build fails In-Reply-To: <1120516918.6657.139.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> <1120512880.18966.46.camel@cutter> <1120514259.6657.117.camel@mccallum.corsepiu.local> <1120515367.18966.50.camel@cutter> <1120516918.6657.139.camel@mccallum.corsepiu.local> Message-ID: <1120521168.4707.18.camel@localhost> On Tue, 2005-07-05 at 00:41 +0200, Ralf Corsepius wrote: > On Mon, 2005-07-04 at 18:16 -0400, seth vidal wrote: > > > So it's okay for you to call a developer and maintainer a jerk? > Did I say you are a jerk? > > Let me cite what I wrote: "Closing PRs in bugzilla, doesn't help end > users which are stuck with a problem and are eagerly waiting for you to > provide a fix, and lets appear you as a jerk to them." > > > So it's okay for you to call a developer and maintainer a jerk? > > Read again what I wrote. I ment to say "end users will consider > maintainers closing PRs without proving fixes/fixed packages to be > jerks." > > You closed PRs without proving fixes and continue to ship broken > packages. End users will draw their conclusions. Here are my conclusions as an end user of this list: 1) You are on the wrong list for logical trickery 2) comments should be sent off list. Given: If A, B If B, C "Seth=A" >From the above, one can conclude that, If A, C "Seth=B" "Seth=C" If you had said "Jerks close PRs without proving fixes" (if C, B) then you would have left yourself a loophole since good guys could also close PRs without proving fixes too. Please stop being a C, Ralf, and please feel free to correct my logic if I am wrong as this is supposed to be a friendly collaborative project. /Mike From rc040203 at freenet.de Tue Jul 5 00:33:24 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jul 2005 02:33:24 +0200 Subject: Re: mock build fails In-Reply-To: <1120521168.4707.18.camel@localhost> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> <1120485012.18966.1.camel@cutter> <1120488653.6657.64.camel@mccallum.corsepiu.local> <1120497145.18966.20.camel@cutter> <1120512586.6657.106.camel@mccallum.corsepiu.local> <1120512880.18966.46.camel@cutter> <1120514259.6657.117.camel@mccallum.corsepiu.local> <1120515367.18966.50.camel@cutter> <1120516918.6657.139.camel@mccallum.corsepiu.local> <1120521168.4707.18.camel@localhost> Message-ID: <1120523604.6657.205.camel@mccallum.corsepiu.local> On Mon, 2005-07-04 at 19:52 -0400, Michael Wiktowy wrote: > On Tue, 2005-07-05 at 00:41 +0200, Ralf Corsepius wrote: > 2) comments should be sent off list. Apologies. This was ment to be sent to Seth only, but I missed to edit the recipient accordingly. Ralf From aoliva at redhat.com Tue Jul 5 03:50:23 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Jul 2005 00:50:23 -0300 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120493698.19467.76.camel@hades.cambridge.redhat.com> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120493698.19467.76.camel@hades.cambridge.redhat.com> Message-ID: On Jul 4, 2005, David Woodhouse wrote: > On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: >> Yes, it's binutils for little-endian MIPS processors. This is the >> first package in the mipsel toolchain. > Can we not have binutils-multi instead? Although opcodes, bfd, binutils executables and ld support multiple targets, gas doesn't, which sort of defeats the point of a single toolchain with --enable-targets=all, if that's what you meant. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 5 05:49:21 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 05 Jul 2005 07:49:21 +0200 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120493698.19467.76.camel@hades.cambridge.redhat.com> (David Woodhouse's message of "Mon, 04 Jul 2005 17:14:57 +0100") References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120493698.19467.76.camel@hades.cambridge.redhat.com> Message-ID: <871x6dpztq.fsf@kosh.bigo.ensc.de> dwmw2 at infradead.org (David Woodhouse) writes: >> Yes, it's binutils for little-endian MIPS processors. This is the >> first package in the mipsel toolchain. > > Can we not have binutils-multi instead? ACK; but this will be only possible for a subset of binutils (objdump, nm, ...) which can be build with '--enable-targets=all'. To reduce maintainance there should be some support from Fedora Core, e.g. handling objdump et.al. through 'alternative': normal binutils are built for actual architecture only and Fedora Extras can provide an alternative 'cross-binutils' package which ships binaries for cross-tools. User can switch with 'alternatives --set binutils ...' betwen both variants. The assembler 'as' and linker 'ld' have to be built for every architecture (perhaps 10-15 interesting ones) separately. It will create lot of overhead both in size and maintenance when there will be used one src.rpm file per architecture. So it would be the best when there is one src.rpm which creates the mentioned programs per architecture. There are two options: it creates a huge 'cross-as' package which contains the assembler for 10-15 architecture, or it creates 10-15 small packages which handle one architecture per package. First option is easy to implement, but I would have to install 9-14 unwanted programs when I want one architecture only. Second option requires some rpm-magic (buildsystem forbids '--define'), but it is doable. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Tue Jul 5 07:13:16 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 05 Jul 2005 09:13:16 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <42C96303.9050900@hhs.nl> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <42C96303.9050900@hhs.nl> Message-ID: <42CA330C.8050207@hhs.nl> Hans de Goede wrote: > Enough discussion what about the real subject of the mail, not the ps. > > The strange failing of gnumeric to build appearantly due to a missing > BuildReq for libpng-devel, which should not be nescesarry since other > Builddeps depend on libpng-devel > > Thanks, > > Hans > Erm, I'm getting more "Build Result: gnumeric on development" mails without requesting mails does that mean that someone is looking into this or ....? Regards, Hans From bugs.michael at gmx.net Tue Jul 5 07:53:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jul 2005 09:53:20 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <42CA330C.8050207@hhs.nl> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <42C96303.9050900@hhs.nl> <42CA330C.8050207@hhs.nl> Message-ID: <20050705095320.344b2bd6.bugs.michael@gmx.net> On Tue, 05 Jul 2005 09:13:16 +0200, Hans de Goede wrote: > > > Hans de Goede wrote: > > Enough discussion what about the real subject of the mail, not the ps. > > > > The strange failing of gnumeric to build appearantly due to a missing > > BuildReq for libpng-devel, which should not be nescesarry since other > > Builddeps depend on libpng-devel > > > > Thanks, > > > > Hans > > > > Erm, > > I'm getting more "Build Result: gnumeric on development" mails without > requesting mails does that mean that someone is looking into this or ....? Restarting the build system apparently re-process all entries in the current "tobuild" file and builds them again. A major reason why to clean up the file from time to time. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1411_FC5 loadavg: 1.68 1.50 1.30 From qiujian2008 at vip.sina.com Tue Jul 5 07:21:59 2005 From: qiujian2008 at vip.sina.com (qiujian) Date: Tue, 05 Jul 2005 15:21:59 +0800 Subject: header intact Message-ID: <1120548120.6475.0.camel@fedora.jichengbu.com> From j.w.r.degoede at hhs.nl Tue Jul 5 10:25:25 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 05 Jul 2005 12:25:25 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <20050705095320.344b2bd6.bugs.michael@gmx.net> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <42C96303.9050900@hhs.nl> <42CA330C.8050207@hhs.nl> <20050705095320.344b2bd6.bugs.michael@gmx.net> Message-ID: <42CA6015.20500@hhs.nl> Michael Schwendt wrote: > On Tue, 05 Jul 2005 09:13:16 +0200, Hans de Goede wrote: > > >> >>Hans de Goede wrote: >> >>>Enough discussion what about the real subject of the mail, not the ps. >>> >>>The strange failing of gnumeric to build appearantly due to a missing >>>BuildReq for libpng-devel, which should not be nescesarry since other >>>Builddeps depend on libpng-devel >>> >>>Thanks, >>> >>>Hans >>> >> >>Erm, >> >>I'm getting more "Build Result: gnumeric on development" mails without >>requesting mails does that mean that someone is looking into this or ....? > > > Restarting the build system apparently re-process all entries in the > current "tobuild" file and builds them again. A major reason why to > clean up the file from time to time. > OK, That still leaves the question what todo with my BUILD-failure. See my original mail. I'm not sure but this feels like a buildsys bug. Can you or someoneelse take a look? Regards, Hans From sarantis at cnl.di.uoa.gr Tue Jul 5 11:22:04 2005 From: sarantis at cnl.di.uoa.gr (Sarantis Paskalis) Date: Tue, 5 Jul 2005 14:22:04 +0300 Subject: Self-Introduction: Sarantis Paskalis Message-ID: <20050705112204.GA5157@gallagher.di.uoa.gr> Full legal name: Sarantis Paskalis City, Country: Athens, Greece Profession or Student Status: Network Engineer Company or School: University of Athens Your goals in the Fedora Project: - Which packages do you want to see published? I would like to help package greek fonts, to promote the ease of use of greek in Linux. The fonts packages are very low overhead, but especially important to certain classes of users. - Do you want to do QA? Yes (C programs, tetex subpackages, fonts) - Anything else special? I use Red Hat since 1997, and I have learned a lot from it. Historical qualifications - What other projects have you worked on in the past? I have worked with the privoxy project (packaging, small bug fixes). - What computer languages and other skills do you know? C, a little bit of shell scripts, LaTeX - Why should we trust you? Well, in my opinion trust is not binary. My guess is that my tiny credentials and my commitment to maintain the (admittedly low overhead) greek fonts could be enough to gain the trust needed. I have contributed some bug fixes in the specfiles of tetex-font-kerkis, to the point that I do not think any other fix is currently necessary. My motivation is to give back to the community that has given much to me. GPG KEYID and fingerprint sarantis at gallagher:~$ gpg --fingerprint D8C9602B pub 1024D/D8C9602B 2005-06-27 [expires: 2006-06-27] Key fingerprint = 79E4 7048 E2CD 1589 396D D869 A455 E1CE D8C9 602B uid Sarantis Paskalis (Fedora Extras) sub 2048g/3AD0CCA5 2005-06-27 [expires: 2006-06-27] -- Sarantis From bugs.michael at gmx.net Tue Jul 5 11:25:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jul 2005 13:25:00 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <42CA6015.20500@hhs.nl> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <42C96303.9050900@hhs.nl> <42CA330C.8050207@hhs.nl> <20050705095320.344b2bd6.bugs.michael@gmx.net> <42CA6015.20500@hhs.nl> Message-ID: <20050705132500.4b64b192.bugs.michael@gmx.net> On Tue, 05 Jul 2005 12:25:25 +0200, Hans de Goede wrote: > That still leaves the question what todo with my BUILD-failure. See my > original mail. I'm not sure but this feels like a buildsys bug. Can you > or someoneelse take a look? Well, the pkg-config failures are due to bug #161688, which is fixed since cairo-devel-0.5.1-4. Whether the build system accesses an up-to-date FC Devel repository, I don't know. Further, whether and why and under which circumstances the buildsys starts rpmbuilding packages with missing build requirements, I don't know either. gnumeric from FE CVS builds fine here for FC Devel. Outside mock that is. If you can reproduce a build failure in mock, you have something to debug. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1411_FC5 loadavg: 1.28 1.12 1.44 From sarantis at cnl.di.uoa.gr Tue Jul 5 11:36:21 2005 From: sarantis at cnl.di.uoa.gr (Sarantis Paskalis) Date: Tue, 5 Jul 2005 14:36:21 +0300 Subject: Take 2: greek font packages Message-ID: <20050705113621.GB5157@gallagher.di.uoa.gr> Hi again, I had not previously posted my self-introduction, so I just did. Regarding the packages I am willing to maintain, there have been two comments for them (from Michael Peters and Michael Schwendt, thanks), which I have incorporated. The updated spec files, srpms and rpms for mgopen-fonts and tetex-font-kerkis are in http://gallagher.di.uoa.gr/any/rpms/ Regarding the packages, tetex-font-kerkis is currently in the FC4 and devel branches in a good shape after Michael Schwendt already incorporated the patches I submitted through bugzilla. The comments for mgopen-fonts were applied and no other issues were identified. One of the reasons for the delay is that I had applied under a different email address (paskalis at di.uoa.gr) than this one that I use for reading and answering fedora mail. Could someone please remove my first application, so that I can reapply with this email address (sarantis at cnl.di.uoa.gr)? Thanks for any feedback. -- Sarantis From bugs.michael at gmx.net Tue Jul 5 11:59:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jul 2005 13:59:22 +0200 Subject: Take 2: greek font packages In-Reply-To: <20050705113621.GB5157@gallagher.di.uoa.gr> References: <20050705113621.GB5157@gallagher.di.uoa.gr> Message-ID: <20050705135922.18693fee.bugs.michael@gmx.net> On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > One of the reasons for the delay is that I had applied under a > different email address (paskalis at di.uoa.gr) than this one that I use > for reading and answering fedora mail. Could someone please remove > my first application, so that I can reapply with this email address > (sarantis at cnl.di.uoa.gr)? In the cvs accounts system? Can't you log in and change your e-mail address there? (before requesting the CLA again) -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1411_FC5 loadavg: 1.46 1.25 1.17 From sarantis at cnl.di.uoa.gr Tue Jul 5 12:41:28 2005 From: sarantis at cnl.di.uoa.gr (Sarantis Paskalis) Date: Tue, 5 Jul 2005 15:41:28 +0300 Subject: Take 2: greek font packages In-Reply-To: <20050705135922.18693fee.bugs.michael@gmx.net> References: <20050705113621.GB5157@gallagher.di.uoa.gr> <20050705135922.18693fee.bugs.michael@gmx.net> Message-ID: <20050705124128.GC5157@gallagher.di.uoa.gr> On Tue, Jul 05, 2005 at 01:59:22PM +0200, Michael Schwendt wrote: > On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > > > One of the reasons for the delay is that I had applied under a > > different email address (paskalis at di.uoa.gr) than this one that I use > > for reading and answering fedora mail. Could someone please remove > > my first application, so that I can reapply with this email address > > (sarantis at cnl.di.uoa.gr)? > > In the cvs accounts system? Can't you log in and change your e-mail > address there? (before requesting the CLA again) Duh! The most annoying thing is that I actually browsed that page and completely missed the thing that I could change my email address. Thanks a lot. -- Sarantis From skvidal at phy.duke.edu Tue Jul 5 12:56:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Jul 2005 08:56:35 -0400 Subject: konversation build failure In-Reply-To: <200507031332.26008.dennis@ausil.us> References: <200507031332.26008.dennis@ausil.us> Message-ID: <1120568195.18966.83.camel@cutter> On Sun, 2005-07-03 at 13:32 -0500, Dennis Gilmore wrote: > ok i fixed x86_64 build but got an error on ppc > Rebuild source rpm konversation-0.18-4.fc5.src.rpm > ERROR: something went wrong rebuilding the .src.rpm > ERROR: inspect rpm build > log /var/tmp/mach/fedora-development-ppc-core/konversation-0.18-4.fc5/rpm.log > ERROR: failed to rebuild SRPMs > > > is that a build system issue? should i resubmit or can i get the rpm.log to > see what happened? and try and work it out. > I don't have a good answer for it. I had to restart the buildsystem this weekend. And I noticed that for a few minutes the buildsystem seemed to have been unable to access cvs. That may have been it. -sv From skvidal at phy.duke.edu Tue Jul 5 12:59:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Jul 2005 08:59:53 -0400 Subject: Strange build errors (buildsys bug?) In-Reply-To: <42CA330C.8050207@hhs.nl> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <42C96303.9050900@hhs.nl> <42CA330C.8050207@hhs.nl> Message-ID: <1120568393.18966.88.camel@cutter> On Tue, 2005-07-05 at 09:13 +0200, Hans de Goede wrote: > > Hans de Goede wrote: > > Enough discussion what about the real subject of the mail, not the ps. > > > > The strange failing of gnumeric to build appearantly due to a missing > > BuildReq for libpng-devel, which should not be nescesarry since other > > Builddeps depend on libpng-devel > > > > Thanks, > > > > Hans > > > > Erm, > > I'm getting more "Build Result: gnumeric on development" mails without > requesting mails does that mean that someone is looking into this or ....? Yes. I restarted the buildsystem yesterday b/c it had stopped doing anything. Any job that had not been processed yet and some that had got reprocessed. Generally, it doesn't hurt anything for them to built again. -sv From paul at city-fan.org Tue Jul 5 13:03:08 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 05 Jul 2005 14:03:08 +0100 Subject: konversation build failure In-Reply-To: <1120568195.18966.83.camel@cutter> References: <200507031332.26008.dennis@ausil.us> <1120568195.18966.83.camel@cutter> Message-ID: <42CA850C.1090109@city-fan.org> seth vidal wrote: > On Sun, 2005-07-03 at 13:32 -0500, Dennis Gilmore wrote: > >>ok i fixed x86_64 build but got an error on ppc >>Rebuild source rpm konversation-0.18-4.fc5.src.rpm >>ERROR: something went wrong rebuilding the .src.rpm >>ERROR: inspect rpm build >>log /var/tmp/mach/fedora-development-ppc-core/konversation-0.18-4.fc5/rpm.log >>ERROR: failed to rebuild SRPMs >> >> >>is that a build system issue? should i resubmit or can i get the rpm.log to >>see what happened? and try and work it out. >> > > > I don't have a good answer for it. I had to restart the buildsystem this > weekend. And I noticed that for a few minutes the buildsystem seemed to > have been unable to access cvs. That may have been it. I got one of those today: Rebuild source rpm bittorrent-4.1.2-2.fc5.src.rpm ERROR: something went wrong rebuilding the .src.rpm ERROR: inspect rpm build log /var/tmp/mach/fedora-development-i386-core/bittorrent-4.1.2-2.fc5/rpm.log ERROR: failed to rebuild SRPMs Package builds fine locally. Paul. From jspaleta at gmail.com Tue Jul 5 13:29:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 5 Jul 2005 09:29:20 -0400 Subject: Strange build errors (buildsys bug?) In-Reply-To: <1120486056.6657.57.camel@mccallum.corsepiu.local> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <1120486056.6657.57.camel@mccallum.corsepiu.local> Message-ID: <604aa791050705062940cb4678@mail.gmail.com> On 7/4/05, Ralf Corsepius wrote: > The package even lacks the fe4-config files. The fc4 package right now defaults to be configured to use the development tree.. ironically... that is EXACTLY what Hans wants mock to do..build against the development tree. I don't know why you insist on bring up a tangential issue that only serve to confuse discussion in a thread. -jef"thinks text to description of 'nextrelease' is sorely needed to help explain to some people its purpose as compared to 'currentrelease' "spaleta From ivazquez at ivazquez.net Tue Jul 5 13:34:20 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Jul 2005 09:34:20 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120494522.15363.19.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> <1120488948.6657.68.camel@mccallum.corsepiu.local> <1120491323.15363.14.camel@ignacio.ignacio.lan> <1120493367.6657.80.camel@mccallum.corsepiu.local> <1120494522.15363.19.camel@ignacio.ignacio.lan> Message-ID: <1120570460.15363.42.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 12:28 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-07-04 at 18:09 +0200, Ralf Corsepius wrote: > > BTW: I'd recommend not to use "mipssel-linux" as target tuple, but to > > use a fully expanded target tuple, matching the target OS you actually > > are addressing, e.g. mipssel-redhat-linux. > > TBH I don't really *have* a target OS per se; I'm building the toolchain > in order to get Linux (most likely LFS) running on a HPC. But if it > helps create a mipsel branch for Rawhide then I'll go ahead and change > it. opcodes gave me this: checking target system type... Invalid configuration `mipsel-redhat-linux-elf': machine `mipsel-redhat-linux' not recognized So much for *that* plan... -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 bugs.michael at gmx.net Tue Jul 5 13:54:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jul 2005 15:54:46 +0200 Subject: konversation build failure In-Reply-To: <42CA850C.1090109@city-fan.org> References: <200507031332.26008.dennis@ausil.us> <1120568195.18966.83.camel@cutter> <42CA850C.1090109@city-fan.org> Message-ID: <20050705155446.38033c1d.bugs.michael@gmx.net> On Tue, 05 Jul 2005 14:03:08 +0100, Paul Howarth wrote: [Seth] > > I don't have a good answer for it. I had to restart the buildsystem this > > weekend. And I noticed that for a few minutes the buildsystem seemed to > > have been unable to access cvs. That may have been it. > > I got one of those today: > > Rebuild source rpm bittorrent-4.1.2-2.fc5.src.rpm > ERROR: something went wrong rebuilding the .src.rpm > ERROR: inspect rpm build log > /var/tmp/mach/fedora-development-i386-core/bittorrent-4.1.2-2.fc5/rpm.log > ERROR: failed to rebuild SRPMs > > Package builds fine locally. A private message from Seth plus my observations in bug 159414 seem to indicate that bumping release and re-requesting a build should fix it. Please give it a try, whoever runs into this. If it seems to fail permanently, add yourself to bug 159414. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1411_FC5 loadavg: 1.54 1.26 1.19 From byte at aeon.com.my Tue Jul 5 14:18:29 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 05 Jul 2005 22:18:29 +0800 Subject: mock build fails In-Reply-To: <1120468806.6657.45.camel@mccallum.corsepiu.local> References: <42C8F632.2050707@hhs.nl> <1120468806.6657.45.camel@mccallum.corsepiu.local> Message-ID: <1120573110.18983.50.camel@potter.soho.bytebot.net> On Mon, 2005-07-04 at 11:20 +0200, Ralf Corsepius wrote: > In a nutshell: The version in FE is doesn't support selinux, > completely > broken and non-functional, the version from the mock repository in > Fedora's CVS also still has selinux probs, but is more or less > functional. FWIW, SELinux doesn't deal well with chroot styled-ed environments. We ship Xen in Core, and clearly, SELinux and Xen don't play well with each other -- Colin Charles, http://www.bytebot.net/ From ivazquez at ivazquez.net Tue Jul 5 14:48:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Jul 2005 10:48:25 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120480073.15363.7.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> Message-ID: <1120574905.15363.49.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec > http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src.rpm Updated. Please re-review. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 fedora at camperquake.de Tue Jul 5 14:59:53 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Jul 2005 16:59:53 +0200 Subject: Request for Review: libevent In-Reply-To: <20050704174535.269e5206@nausicaa.camperquake.de> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> <42C5F4C0.2000700@di.uminho.pt> <20050704174535.269e5206@nausicaa.camperquake.de> Message-ID: <20050705165953.2084f852@nausicaa.camperquake.de> Hi. Ralf Ertzinger wrote: > Thanks, package is in CVS now. May I consider the package to be approved? -- "It's one of those irregular verbs: I explore the possibilities of computing, you hack, he has been charged under section 2 of the computer misuse act..." -- Richard Watts From lmacken at redhat.com Tue Jul 5 15:29:55 2005 From: lmacken at redhat.com (Luke Macken) Date: Tue, 5 Jul 2005 11:29:55 -0400 Subject: Request for Review: naim Message-ID: <20050705152955.GA13111@tomservo.boston.redhat.com> naim is a console client for AOL Instant Messenger (AIM), AOL I Seek You (ICQ), Internet Relay Chat (IRC), and The lily CMC. http://people.redhat.com/lmacken/naim.spec http://people.redhat.com/lmacken/naim-0.11.7.3.1-1.src.rpm Thanks, luke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Tue Jul 5 16:22:37 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 5 Jul 2005 11:22:37 -0500 Subject: ddrescue and dd_rescue In-Reply-To: References: <42C4FE44.5010108@redhat.com> <1120206990.2815.222.camel@localhost.localdomain> <42C51D38.4050101@redhat.com> <20050702193013.GA15992@osiris.silug.org> Message-ID: <20050705162237.GA30566@osiris.silug.org> On Sat, Jul 02, 2005 at 10:43:50PM +0200, Andreas Thienemann wrote: > I'm happy to package both and also maintain the ddrescue and the dd_rescue > package as well. > If you'd send me your dd_rhelp package, I'll do that as well. Cool. Consider it done (later today). 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 fedora at camperquake.de Tue Jul 5 16:55:46 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Jul 2005 18:55:46 +0200 Subject: Request for review: tor Message-ID: <20050705185546.2c85e798@nausicaa.camperquake.de> Hi. With libevent in FE now, here is a reworked tor package for new review. http://www.skytale.net/files/tor/tor-0.1.0.11-2.sky.src.rpm -- Many rebel spies have died for this information. From orion at cora.nwra.com Tue Jul 5 20:18:57 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 05 Jul 2005 14:18:57 -0600 Subject: Request for Approval: hdf5 In-Reply-To: <1120488754.10305.8.camel@ernie> References: <1119989530.3226.7.camel@localhost.localdomain> <1120002949.2513.7.camel@localhost.localdomain> <1120089574.2513.158.camel@localhost.localdomain> <42C41DA9.5060609@cora.nwra.com> <42C567E0.3040708@cora.nwra.com> <1120488754.10305.8.camel@ernie> Message-ID: <42CAEB31.4030203@cora.nwra.com> Ed Hill wrote: > On Fri, 2005-07-01 at 09:57 -0600, Orion Poplawski wrote: >>Latest versions: >> >>http://www.cora.nwra.com/~orion/fedora/hdf5-1.6.4-3.src.rpm >>http://www.cora.nwra.com/~orion/fedora/hdf5.spec >> >>Please review (and/or approve) > > Perhaps (?) needs work: > - rpmlint hdf5: > - about a dozen %doc files have execute permissions set when > they should probably be just 644 Fixed. > - a few end-of-line encoding warnings on %doc files but > they're HTML so would anyone care...? I say no. > - rpmlint hdf5-devel: > W: hdf5-devel no-provides hdf-devel Everyone is expected to use -lhdf5, not -lhdf. > W: hdf5-devel summary-not-capitalized hdf5 development files > Fixed. > > Please fix the permissions and take a look at the warnings. Since its > all just minor stuff, I'll send an approved message soon. > > Ed > I've checked it into CVS (version 1.6.4-4). -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From tcallawa at redhat.com Tue Jul 5 20:44:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Jul 2005 15:44:14 -0500 Subject: Request for Approval: hdf5 In-Reply-To: <42CAEB31.4030203@cora.nwra.com> References: <1119989530.3226.7.camel@localhost.localdomain> <1120002949.2513.7.camel@localhost.localdomain> <1120089574.2513.158.camel@localhost.localdomain> <42C41DA9.5060609@cora.nwra.com> <42C567E0.3040708@cora.nwra.com> <1120488754.10305.8.camel@ernie> <42CAEB31.4030203@cora.nwra.com> Message-ID: <1120596254.30349.42.camel@localhost.localdomain> On Tue, 2005-07-05 at 14:18 -0600, Orion Poplawski wrote: > > - rpmlint hdf5-devel: > > W: hdf5-devel no-provides hdf-devel > > Everyone is expected to use -lhdf5, not -lhdf. This is just rpmlint being stupid. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From orion at cora.nwra.com Tue Jul 5 20:49:53 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 05 Jul 2005 14:49:53 -0600 Subject: Request for review: pytz and python-dateutil Message-ID: <42CAF271.50401@cora.nwra.com> I'm attempting to shift my python-matplotlib package to use upstream versions of pytz and dateutil. It bundles a version of each with it, but will not install if already present. So, it seems best to provide official versions of pytz and python-dateutil and have python-matplotlib require these to be present at build. So: pytz - World Timezone Definitions for Python Author: Stuart Bishop Introduction pytz brings the Olson tz database into Python. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. It also solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson timezones are supported [*]. http://pytz.sourceforge.net/ Package at: http://www.cora.nwra.com/~orion/fedora/pytz.spec http://www.cora.nwra.com/~orion/fedora/pytz-2005i-1.src.rpm python-dateutil: Description: The dateutil module provides powerful extensions to the standard datetime module, available in Python 2.3+. https://moin.conectiva.com.br/DateUtil Package at: http://www.cora.nwra.com/~orion/fedora/python-dateutil.spec http://www.cora.nwra.com/~orion/fedora/python-dateutil-0.9-1.src.rpm -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From qspencer at ieee.org Tue Jul 5 21:14:50 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 05 Jul 2005 16:14:50 -0500 Subject: Can anyone explain this? Message-ID: <42CAF84A.3040304@ieee.org> I successfully compiled cln on development yesterday, and today tried GiNaC, which has cln as a dependency. No problems on i386 and PPC, but on x86_64, it fails. Looking at the log, it gets through configure OK, and then fails on the first file that is compiled with something like this: g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -MT add.lo -MD -MP -MF .deps/add.Tpo -c add.cpp -fPIC -DPIC -o .libs/add.o /usr/include/cln/number.h: In constructor 'cln::cl_number::cl_number()': /usr/include/cln/number.h:187: error: 'cl_FN_tag' was not declared in this scope (long list of similar errors follows). So, looking at /usr/include/cln/number.h in the cln-devel package, it is indeed identical for the i386 and x86_64 versions of the package as it should be. So why is this failing on x86_64? Could the build system have anything to do with this (doesn't seem likely), is there a problem with g++ that is specific to x86_64, or is there something else going on that I didn't think of? -Quentin From andreas.bierfert at lowlatency.de Tue Jul 5 21:47:04 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Tue, 05 Jul 2005 23:47:04 +0200 Subject: Request for review: koffice In-Reply-To: <42C5C641.6000908@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> Message-ID: <42CAFFD8.2020101@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, I have done some work on koffice again... hence look here: http://fedora.lowlatency.de/review/ - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCyv/YQEQyPsWM8csRAugVAJ0Q4N8KpiGWSYba5dtywnC2YrXihgCfbJii RPaBi8Pn/hMC+JcWmHCi4yY= =qpOB -----END PGP SIGNATURE----- From orion at cora.nwra.com Tue Jul 5 22:16:13 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 05 Jul 2005 16:16:13 -0600 Subject: Request for review: kompose Message-ID: <42CB06AD.4040705@cora.nwra.com> This is my first attempt at packaging a kde app, so there are surely some issues. In particular, I don?t seem to get an icon in my KDE menu, so I must not be installing icons is the right place or the .desktop file must not be right. Description: Kompos? offers a great new way to manage a big number of windows on different Virtual Desktops. It creates a fullscreen view where every window is represented by a scaled screenshot of its own. Thanks to the KDE framework it is possible to create those screenshots "on the fly" while you are working without much overhead. The image scaling is done through the high performance image library Imlib2. Since version 0.5 support for the Composite and Damage extensions has been added, which allows us to display window contents without grabbing screenshots. However with the current state of graphics drivers XOrg may be awfully slow (or even crash sometimes) when enabling the Composite extension. So blame me for your bad gfx drivers :) URL http://kompose.berlios.de/ Package: http://www.cora.nwra.com/~orion/fedora/kompose.spec http://www.cora.nwra.com/~orion/fedora/kompose-0.5.2-0.beta1.src.rpm -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From tcallawa at redhat.com Wed Jul 6 00:15:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Jul 2005 19:15:08 -0500 Subject: Request for Review: opendap In-Reply-To: <1119141334.9216.40.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> Message-ID: <1120608908.30349.59.camel@localhost.localdomain> In a stunning blast from the past, I present... opendap! This originally had a review request in April, but its fixed up, and back for another try. On Sat, 2005-06-18 at 20:35 -0400, Ed Hill wrote: > I realize that its been months since you put time and effort into the > opendap package, but I finally found some free time today to take a hard > look at it. And found a litany of problems including: > > - opendap-devel pollutes /usr/include with dozens of header > files many of which have very generic names The new package uses /usr/include/opendap > - some the binaries (eg. Ncview) that it installs immediately > seg-fault when run -- they're totally useless The broken client binaries are totally useless, so I removed them altogether. > - it conflicts with a different ncview package that I'd > like to separately submit to extras which actually > *does* work The new package doesn't conflict with Ed's other ncview package. > - the opendap-config binary reports nonsense such as: > > [edhill at ernie i386]# /usr/bin/opendap-config --cflags > -I/home/edhill/rpmbuild/BUILD/opendap-3.4.4/DODS/include > > which shows that its grabbing paths from the build > location and not the install location :-( opendap-config no longer reports nonsense. Its a little verbose, but its all correct now (pathing is right). opendap now comes with shared libraries, instead of only static. While I'm sure there are other issues, all the blockers should be gone. Other issues can be filed in bugzilla. I considered packaging libdap instead (I even have a working spec for it), but I opted against that for the time being, because most applications still need opendap libraries (libdap doesn't provide libnc-dods) and libdap is still in beta. SRPM: http://www.auroralinux.org/people/spot/review/opendap-3.4.4-4.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec Please review, so I can get this monkey off my back. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From dennis at ausil.us Wed Jul 6 00:26:20 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 5 Jul 2005 19:26:20 -0500 Subject: konversation build failure In-Reply-To: <1120568195.18966.83.camel@cutter> References: <200507031332.26008.dennis@ausil.us> <1120568195.18966.83.camel@cutter> Message-ID: <200507051926.20943.dennis@ausil.us> Once upon a time Tuesday 05 July 2005 7:56 am, seth vidal wrote: > On Sun, 2005-07-03 at 13:32 -0500, Dennis Gilmore wrote: > > ok i fixed x86_64 build but got an error on ppc > > Rebuild source rpm konversation-0.18-4.fc5.src.rpm > > ERROR: something went wrong rebuilding the .src.rpm > > ERROR: inspect rpm build > > log > > /var/tmp/mach/fedora-development-ppc-core/konversation-0.18-4.fc5/rpm.log > > ERROR: failed to rebuild SRPMs > > > > > > is that a build system issue? should i resubmit or can i get the rpm.log > > to see what happened? and try and work it out. > > I don't have a good answer for it. I had to restart the buildsystem this > weekend. And I noticed that for a few minutes the buildsystem seemed to > have been unable to access cvs. That may have been it. > i got an email last night saying that the build had succeded on both devel and fc4 must have got stuck in some queue and got rebuilt after the reboot. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ed at eh3.com Wed Jul 6 01:39:04 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 05 Jul 2005 21:39:04 -0400 Subject: Request for review: ncview In-Reply-To: <1120608908.30349.59.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> Message-ID: <1120613945.10305.232.camel@ernie> On Tue, 2005-07-05 at 19:15 -0500, Tom 'spot' Callaway wrote: > > - it conflicts with a different ncview package that I'd > > like to separately submit to extras which actually > > *does* work > > The new package doesn't conflict with Ed's other ncview package. Hi folks, In addition to Spot's freshly polished opendap version, I'd like to submit this ncview package for review: http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-2.src.rpm http://mitgcm.org/eh3/fedora_misc/ncview.spec It compiles and works for me on FC3 and FC4. Ncview is a great little interactive utility for creating 1D/2D plots of numerical data stored in netCDF files. It can do animated loops and can write output to files which, when combined with simple shell/ImageMagick scripts, is a very convenient way to create simple "movies". Please point out any blockers and I'll fix them ASAP. thank you, Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From jspaleta at gmail.com Wed Jul 6 01:51:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 5 Jul 2005 21:51:06 -0400 Subject: New Package: glabels In-Reply-To: <604aa79105070518431e890f6c@mail.gmail.com> References: <604aa79105070518431e890f6c@mail.gmail.com> Message-ID: <604aa791050705185152c0c57@mail.gmail.com> Fellow Fedorians, I hearby request for initial inclusion into the fedora extras cvs this glabels package. >From the project website http://glabels.sourceforge.net/ : "gLabels is a program for creating labels and business cards for the GNOME desktop environment. It is designed to work with various laser/ink-jet peel-off label and business card sheets that you'll find at most office supply stores. gLabels is free software and is distributed under the terms of the GNU General Public License (GPL)." Spec file: http://jef.is-a-geek.com/downloads/glabels/glabels.spec SRPM: http://jef.is-a-geek.com/downloads/glabels/glabels-2.0.3-1.src.rpm Mock built rpm: http://jef.is-a-geek.com/downloads/glabels/glabels-2.0.3-1-fc5.i386.rpm http://jef.is-a-geek.com/downloads/glabels/glabels-devel-2.0.3-1-fc5.i386.rpm Signed md5sums: http://jef.is-a-geek.com/downloads/glabels/MD5SUMS The srpm builds against the fedora development tree fine inside mock. rpmlint against the mock built rpm only spits out a warning about the changelog: W: glabels incoherent-version-in-changelog 2.0.3-1 2.0.3-1.fc5 This is clearly the result of the disttag macro. I humbly await feedback and/or approval. -jef From oliver at linux-kernel.at Wed Jul 6 07:18:24 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 06 Jul 2005 09:18:24 +0200 Subject: Request for Review: libstatgrab Message-ID: <42CB85C0.4000008@linux-kernel.at> Hi! I'm still awaiting review for the libstatgrab package. libstatgrab: Make system statistics Description: Libstatgrab is a library that provides cross platform access to statistics about the system on which it's run. It's written in C and presents a selection of useful interfaces which can be used to access key system statistics. The current list of statistics includes CPU usage, memory utilisation, disk usage, process counts, network traffic, disk I/O, and more. The current list of platforms is Solaris 2.x, Linux, and FreeBSD 4.x/5.x. The aim is to extend this to include as many operating systems as possible. The package also includes a couple of useful tools. The first, saidar, provides a curses-based interface to viewing the current state of the system. The second, statgrab, gives a sysctl-style interface to the statistics gathered by libstatgrab. This extends the use of libstatgrab to people writing scripts or anything else that can't easily make C function calls. Included with statgrab is a script to generate an MRTG configuration file to use statgrab. SRPM/SPEC: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libstatgrab Please review or approve it! Thanks, Oliver From bugs.michael at gmx.net Wed Jul 6 07:22:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 09:22:43 +0200 Subject: Can anyone explain this? In-Reply-To: <42CAF84A.3040304@ieee.org> References: <42CAF84A.3040304@ieee.org> Message-ID: <20050706092243.2e4c4828.bugs.michael@gmx.net> On Tue, 05 Jul 2005 16:14:50 -0500, Quentin Spencer wrote: > I successfully compiled cln on development yesterday, and today tried > GiNaC, which has cln as a dependency. No problems on i386 and PPC, but > on x86_64, it fails. Looking at the log, it gets through configure OK, > and then fails on the first file that is compiled with something like this: > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -m64 -mtune=nocona -MT add.lo -MD -MP -MF .deps/add.Tpo -c > add.cpp -fPIC -DPIC -o .libs/add.o > /usr/include/cln/number.h: In constructor 'cln::cl_number::cl_number()': > /usr/include/cln/number.h:187: error: 'cl_FN_tag' was not declared in > this scope > (long list of similar errors follows). > > So, looking at /usr/include/cln/number.h in the cln-devel package, it is > indeed identical for the i386 and x86_64 versions of the package as it > should be. So why is this failing on x86_64? Could the build system have > anything to do with this (doesn't seem likely), is there a problem with > g++ that is specific to x86_64, or is there something else going on that > I didn't think of? Well, this would best be examined on an x86_64 system running Rawhide, so you could take a look at the preprocessed input and see whether all the #defines do well. In particular those that depend on type sizes. cln/object.h defines cl_FN_tag, and in number.h it is used much earlier (line 31) than line 187 where the compiler complains about it. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 1.17 1.32 1.40 From paul at city-fan.org Wed Jul 6 07:31:37 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 06 Jul 2005 08:31:37 +0100 Subject: Icons and menus Message-ID: <1120635097.15736.264.camel@laurel.intra.city-fan.org> Yesterday I got a bug report on the bittorrent-gui package, the issue being that no icon appeared in the user's menu for the application. I was unable to reproduce the error; removing the package removed the item from my menu and reinstalling it put it back immediately. However, remembering a similar issue someone mentioned on fedora-list a while back, I suggested that the reporter try restarting gnome. The menu item then appeared for him. Any thoughts on what might be causing this? I do have a postinstall script that does: /usr/bin/update-desktop-database /usr/share/applications &>/dev/null || : Bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162465 Spec: http://cvs.fedora.redhat.com/lxr/extras/source/devel/bittorrent/bittorrent.spec Desktop file: http://cvs.fedora.redhat.com/lxr/extras/source/devel/bittorrent/bittorrent.desktop Paul. -- Paul Howarth From bugs.michael at gmx.net Wed Jul 6 07:42:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 09:42:34 +0200 Subject: rpms/gnome-applet-sensors/devel gnome-applet-sensors.spec,1.2,1.3 In-Reply-To: <200507052304.j65N4xTd006972@cvs-int.fedora.redhat.com> References: <200507052304.j65N4xTd006972@cvs-int.fedora.redhat.com> Message-ID: <20050706094234.2f558d68.bugs.michael@gmx.net> On Tue, 5 Jul 2005 19:04:29 -0400, Aaron Kurtz wrote: > Author: dragoon > > Update of /cvs/extras/rpms/gnome-applet-sensors/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6955 > Log Message: > * Tue Jul 05 2005 Aaron Kurtz - 1.0-2 > - rawhide Cairo dependencies > +#Cairo needs this, so why didn't gnome-panel-devel grab it > +BuildRequires: libpng-devel This is bug #161688, fixed since cairo-devel-0.5.1-4. You should no longer see this unless the build system accesses an out-of-date repository. Debug output like "rpm --query cairo-devel" in %build should tell. From bugs.michael at gmx.net Wed Jul 6 08:17:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 10:17:48 +0200 Subject: rpms/gnome-applet-sensors/devel gnome-applet-sensors.spec,1.2,1.3 In-Reply-To: <20050706094234.2f558d68.bugs.michael@gmx.net> References: <200507052304.j65N4xTd006972@cvs-int.fedora.redhat.com> <20050706094234.2f558d68.bugs.michael@gmx.net> Message-ID: <20050706101748.02ae2039.bugs.michael@gmx.net> On Wed, 6 Jul 2005 09:42:34 +0200, Michael Schwendt wrote: > > +#Cairo needs this, so why didn't gnome-panel-devel grab it > > +BuildRequires: libpng-devel > > This is bug #161688, fixed since cairo-devel-0.5.1-4. You should no longer > see this unless the build system accesses an out-of-date repository. > Debug output like "rpm --query cairo-devel" in %build should tell. Something else in cairo-devel is broken, btw: https://bugzilla.redhat.com/162550 Sylpheed in devel also failed to build as if build system content still depends on bug 161688. My previous build worked around it, but when cairo-devel was fixed, I took out the work-around. From bugs.michael at gmx.net Wed Jul 6 08:21:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 10:21:30 +0200 Subject: Icons and menus In-Reply-To: <1120635097.15736.264.camel@laurel.intra.city-fan.org> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> Message-ID: <20050706102130.0c45c092.bugs.michael@gmx.net> On Wed, 06 Jul 2005 08:31:37 +0100, Paul Howarth wrote: > Yesterday I got a bug report on the bittorrent-gui package, the issue > being that no icon appeared in the user's menu for the application. I > was unable to reproduce the error; removing the package removed the item > from my menu and reinstalling it put it back immediately. However, > remembering a similar issue someone mentioned on fedora-list a while > back, I suggested that the reporter try restarting gnome. The menu item > then appeared for him. Any thoughts on what might be causing this? Never seen it before. Only menu related problem in GNOME I still see is that icons from KDE apps are not displayed until logout/re-login. As if the current icon caching is at fault and doesn't find uncached icons from within an ordinary user's account. > I do > have a postinstall script that does: > > /usr/bin/update-desktop-database /usr/share/applications &>/dev/null > || : This is only for MIME types and doesn't affect menu entries. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 1.21 1.39 1.42 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 6 08:19:45 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 6 Jul 2005 10:19:45 +0200 Subject: Icons and menus In-Reply-To: <1120635097.15736.264.camel@laurel.intra.city-fan.org> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> Message-ID: <20050706101945.207e639c@python2> Paul Howarth wrote : > Yesterday I got a bug report on the bittorrent-gui package, the issue > being that no icon appeared in the user's menu for the application. I > was unable to reproduce the error; removing the package removed the item > from my menu and reinstalling it put it back immediately. However, > remembering a similar issue someone mentioned on fedora-list a while > back, I suggested that the reporter try restarting gnome. The menu item > then appeared for him. Any thoughts on what might be causing this? I do > have a postinstall script that does: > > /usr/bin/update-desktop-database /usr/share/applications &>/dev/null > || : I've also seen similar behavior very often, including today after installing Abiword and Gnumeric from Extras, but I did get the icons for Lbreakout2 and PPRacer that I had installed just minutes before... and I simply can't figure either what the scripts in packages are supposed to do for that not to happen since the above seems to not be sufficient. I also tried explicit calls to gtk-update-icon-cache as many packages do, but it didn't fix the problem for the current session either. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.16 0.25 0.24 From bugs.michael at gmx.net Wed Jul 6 08:45:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 10:45:51 +0200 Subject: Strange build errors (buildsys bug?) In-Reply-To: <20050705132500.4b64b192.bugs.michael@gmx.net> References: <42C92016.9010502@hhs.nl> <1120478183.15363.2.camel@ignacio.ignacio.lan> <42C9240F.2090807@hhs.nl> <1120485083.18966.3.camel@cutter> <42C96303.9050900@hhs.nl> <42CA330C.8050207@hhs.nl> <20050705095320.344b2bd6.bugs.michael@gmx.net> <42CA6015.20500@hhs.nl> <20050705132500.4b64b192.bugs.michael@gmx.net> Message-ID: <20050706104551.2953711d.bugs.michael@gmx.net> On Tue, 5 Jul 2005 13:25:00 +0200, Michael Schwendt wrote: > On Tue, 05 Jul 2005 12:25:25 +0200, Hans de Goede wrote: > > > That still leaves the question what todo with my BUILD-failure. See my > > original mail. I'm not sure but this feels like a buildsys bug. Can you > > or someoneelse take a look? > > Well, the pkg-config failures are due to bug #161688, which is fixed since > cairo-devel-0.5.1-4. Whether the build system accesses an up-to-date FC > Devel repository, I don't know. Buildsys still loads an old cairo-devel-0.5.1-3, which does not include the fix for bug #161688: https://bugzilla.redhat.com/162551 -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 2.64 1.89 1.53 From adrian at lisas.de Wed Jul 6 08:51:18 2005 From: adrian at lisas.de (Adrian Reber) Date: Wed, 6 Jul 2005 10:51:18 +0200 Subject: New Package: glabels In-Reply-To: <604aa791050705185152c0c57@mail.gmail.com> References: <604aa79105070518431e890f6c@mail.gmail.com> <604aa791050705185152c0c57@mail.gmail.com> Message-ID: <20050706085118.GA982@lisas.de> On Tue, Jul 05, 2005 at 09:51:06PM -0400, Jeff Spaleta wrote: > Spec file: > http://jef.is-a-geek.com/downloads/glabels/glabels.spec > > SRPM: > http://jef.is-a-geek.com/downloads/glabels/glabels-2.0.3-1.src.rpm + md5sum verfied against upstream + builds in mock + clean installation and removal verified + application works + %find_lang macro used + correct usage of -devel sub-package + scripts look sane and necessary Requires are present + BuildRequires look good + spec looks good + rpmlint output checked APPROVED Adrian From tarjei.knapstad at gmail.com Wed Jul 6 10:57:37 2005 From: tarjei.knapstad at gmail.com (Tarjei Knapstad) Date: Wed, 6 Jul 2005 12:57:37 +0200 Subject: New Package: Sprog In-Reply-To: <200507022344.03123.ghenry@suretecsystems.com> References: <200507022344.03123.ghenry@suretecsystems.com> Message-ID: On 7/3/05, Gavin Henry wrote: > Dear List, > > SRPM: http://www.perl.me.uk/downloads/Sprog/Sprog-0.12-1.src.rpm > SPEC: http://www.perl.me.uk/downloads/Sprog/Sprog.spec > > Main Site: http://sprog.sourceforge.net/ > Article: http://www.perl.com/pub/a/2005/06/23/sprog.html > > Anyone care to review it? > The webserver seems to be down or unresponsive... I can ping www.perl.me.uk just fine, but the webserver times out so I can't get the files. -- Tarjei From jamatos at fc.up.pt Wed Jul 6 11:23:09 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Wed, 06 Jul 2005 12:23:09 +0100 Subject: Request for review: pytz and python-dateutil References: <42CAF271.50401@cora.nwra.com> Message-ID: Orion Poplawski wrote: Hi, > I'm attempting to shift my python-matplotlib package to use upstream > versions of pytz and dateutil. It bundles a version of each with it, > but will not install if already present. So, it seems best to provide > official versions of pytz and python-dateutil and have python-matplotlib > require these to be present at build. Last friday I sent a message to matplot-users list asking for the author opinion on this subject. In one of the replies John Hunter, matplotlib maintainer, said that matplotlib tar ball has several others python modules inside: - agg - pyparsing - pycxx I will review later both pytz and python-dateutil packages. -- Jos? Ab?lio From ivazquez at ivazquez.net Wed Jul 6 11:37:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Jul 2005 07:37:09 -0400 Subject: Request for review: pytz and python-dateutil In-Reply-To: References: <42CAF271.50401@cora.nwra.com> Message-ID: <1120649829.15363.77.camel@ignacio.ignacio.lan> On Wed, 2005-07-06 at 12:23 +0100, Jos? Matos wrote: > Orion Poplawski wrote: > > Hi, > > > I'm attempting to shift my python-matplotlib package to use upstream > > versions of pytz and dateutil. It bundles a version of each with it, > > but will not install if already present. So, it seems best to provide > > official versions of pytz and python-dateutil and have python-matplotlib > > require these to be present at build. > > Last friday I sent a message to matplot-users list asking for the author > opinion on this subject. In one of the replies John Hunter, matplotlib > maintainer, said that matplotlib tar ball has several others python modules > inside: > - pyparsing https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00429.html http://fedora.ivazquez.net/files/extras/pyparsing-1.3-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 nicolas.mailhot at laposte.net Wed Jul 6 11:41:47 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 6 Jul 2005 13:41:47 +0200 (CEST) Subject: Trademarks In-Reply-To: <1120497799.18966.24.camel@cutter> References: <1120303368.26373.30.camel@localhost.localdomain> <1120493791.19467.79.camel@hades.cambridge.redhat.com> <1120497799.18966.24.camel@cutter> Message-ID: <14978.192.54.193.35.1120650107.squirrel@rousalka.dyndns.org> On Lun 4 juillet 2005 19:23, seth vidal wrote: > On Mon, 2005-07-04 at 17:16 +0100, David Woodhouse wrote: >> On Sat, 2005-07-02 at 09:33 -0500, Ian Pilcher wrote: >> > Ville Skytt?? wrote: >> > > Summary: Supplemental kernel modules for ThinkPad?? laptop computers >> > >> > I would recommend sticking to straight ASCII, maybe ThinkPad(R)? >> >> Why? I think we all ought to be able to handle UTF-8 now. > > as long as folks write the symbol in utf-8 and not in some other odd > encoding. :) This is why aggressively adding UTF-8 symbols in specfiles is good : it clarifies any false assumptions people may have about their encoding. -1 for (R), (C) and other ascii-isms -- Nicolas Mailhot From ivazquez at ivazquez.net Wed Jul 6 12:49:51 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Jul 2005 08:49:51 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120480073.15363.7.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> Message-ID: <1120654191.15363.82.camel@ignacio.ignacio.lan> On Mon, 2005-07-04 at 08:27 -0400, Ignacio Vazquez-Abrams wrote: > http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec > http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src.rpm Updated yet again. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mrdocs at gmail.com Wed Jul 6 13:01:02 2005 From: mrdocs at gmail.com (P Linnell) Date: Wed, 6 Jul 2005 15:01:02 +0200 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <20050706081928.CBA79737E8@hormel.redhat.com> References: <20050706081928.CBA79737E8@hormel.redhat.com> Message-ID: <49e94b5105070606012268b6ed@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We have released a new stable version of Scribus 1.2.2.1. Phil Compton who has worked closely with us on packaging for a while seems to be away on a project, so I have packaged up Scribus as a Source RPM for FC. We would really appreciate someone helping to get this imported into the build system and sent out as an update for FC-3/FC-4, as it has a number of improvements,translation updates, bug fixes and stability. I've tweaked the 1.2.1 spec file to reflect current requirements and the fact that separate plugins and docs are now packaged together. Download locations: http://www.scribus.org.uk/downloads/1.2.2.1/scribus-1.2.2.1.tar.bz2 md5sum 8c2eac0a358b04c39252586d9d85ab24 sha1sum 89dff737856d2d73068d0715fa27aad96262e1a4 http://www.scribus.org.uk/downloads/1.2.2.1/scribus-1.2.2.1.tar.bz2.sig (gpg signed by me) http://www.scribus.org.uk/downloads/1.2.2.1/scribus-1.2.2.1-0.fc4.src.rpm (gpg signed by me) http://www.scribus.org.uk/downloads/1.2.2.1/scribus.fc.spec md5sum db92632a7b727271428f197788fdb0d2 sha1sum c1975f6bd224106da098f236c6667bbc622d6a1f 1.2.1 > 1.2.2.1 changelog: http://www.scribus.org.uk/modules.php?op=modload&name=News&file=article&sid=98 Thanks in advance, Peter Scribus Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCy9Wz73uV5/YBZtoRAhvRAJ9HYhhrgj8K7e3a1V1BJmaTmuCjnQCeKI2B eK+SVRtohceU55R4c1jglt8= =PwHr -----END PGP SIGNATURE----- From tcallawa at redhat.com Wed Jul 6 13:17:48 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 08:17:48 -0500 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <49e94b5105070606012268b6ed@mail.gmail.com> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> Message-ID: <1120655868.30349.86.camel@localhost.localdomain> On Wed, 2005-07-06 at 15:01 +0200, P Linnell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > We have released a new stable version of Scribus 1.2.2.1. Phil Compton > who has worked closely with us on packaging for a while seems to be > away on a project, so I have packaged up Scribus as a Source RPM for > FC. I'm hesitant to override a package maintainer unless Phil says its alright. Phil? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mrdocs at gmail.com Wed Jul 6 13:30:17 2005 From: mrdocs at gmail.com (P Linnell) Date: Wed, 6 Jul 2005 15:30:17 +0200 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <1120655868.30349.86.camel@localhost.localdomain> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> Message-ID: <49e94b51050706063078650c94@mail.gmail.com> On 7/6/05, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 15:01 +0200, P Linnell wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, > > > > We have released a new stable version of Scribus 1.2.2.1. Phil Compton > > who has worked closely with us on packaging for a while seems to be > > away on a project, so I have packaged up Scribus as a Source RPM for > > FC. > > I'm hesitant to override a package maintainer unless Phil says its > alright. Phil? > > ~spot > -- Hi, Not intended to do that... This is only a one time case. Cheers, Peter From nicolas.mailhot at laposte.net Wed Jul 6 13:30:06 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 6 Jul 2005 15:30:06 +0200 (CEST) Subject: New package: icmpdn In-Reply-To: <1119968531.15326.61.camel@pc7.dolda2000.com> References: <1119962800.15326.39.camel@pc7.dolda2000.com> <42C151D4.9060800@linux-kernel.at> <1119968531.15326.61.camel@pc7.dolda2000.com> Message-ID: <28626.192.54.193.35.1120656606.squirrel@rousalka.dyndns.org> On Mar 28 juin 2005 16:22, Fredrik Tolf wrote: = >> * Strange characters show up in %description: ???????? (after icmpdnd, >> idnlookup, libnss_icmp.so.2) in firefox; In vim: ??~@~S > > Hm. It seems that Oron Peled copied my homepage directly into the README > and specfile when he created them, so those are probably en-dashes in > UTF-8. I never noticed, since all my systems handle UTF-8 correctly. > > I might as well fix it (dashes and en-dashes look the same in terminal > fonts anyway), but is there anything wrong with using UTF-8 in > specfiles? As long as it's valid UTF-8 just do everyone a favour and keep the UTF-8 characters. RHL/FC has decided long ago to force UTF-8 adoption because waiting for everyone not affected by ASCII problems to make the jump was irrealistic. And yes it will break some utilities. We want them to break so they are fixed someday. And you do need full UTF-8 in specs at least for people names, because it's plain rude to force humans to mangle their names just to accomodate the laziness of people who happen not to use more than 128 characters in their everyday life. -- Nicolas Mailhot From tcallawa at redhat.com Wed Jul 6 13:40:42 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 08:40:42 -0500 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <49e94b51050706063078650c94@mail.gmail.com> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> <49e94b51050706063078650c94@mail.gmail.com> Message-ID: <1120657242.30349.95.camel@localhost.localdomain> On Wed, 2005-07-06 at 15:30 +0200, P Linnell wrote: > Not intended to do that... This is only a one time case. While I understand, I'm very hesitant to set precedent. If Phil says its OK, then we'll treat it like a new package and review it for submission. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From qspencer at ieee.org Wed Jul 6 14:20:17 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 06 Jul 2005 09:20:17 -0500 Subject: More build problems on x86_64 Message-ID: <42CBE8A1.2020709@ieee.org> I'm getting the following error building octave on x86_64: g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc -DHAVE_CONFIG_H -Wall -W -Wshadow -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -D_GNU_SOURCE Array-s.cc -o pic/Array-s.o g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See for instructions. {standard input}: Assembler messages: {standard input}:141815: Warning: partial line at end of file ignored Originally, this happened on development and I filed a bug report thinking this was a compiler problem. I got the following response to my bug: ------- Additional Comments From jakub at redhat.com 2005-07-05 17:27 EST ------- That means either that you or the kernel killed the compiler. That does not mean there is a compiler bug. A compiler bug would be if on reasonably large source the compiler ate excessive amount of memory and OOM killer killed it. So the question is: 1) how much physical memory and swap do you have 2) run that command again and watch in top how much memory it is using After receiving this message, I tried building octave on FC4, and got the same error on the same source file. The last time I built octave on FC4 there were no problems. I don't really have any way of further debugging this. Any ideas what's going on here? -Quentin From skvidal at phy.duke.edu Wed Jul 6 14:41:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Jul 2005 10:41:18 -0400 Subject: More build problems on x86_64 In-Reply-To: <42CBE8A1.2020709@ieee.org> References: <42CBE8A1.2020709@ieee.org> Message-ID: <1120660879.26751.31.camel@cutter> On Wed, 2005-07-06 at 09:20 -0500, Quentin Spencer wrote: > I'm getting the following error building octave on x86_64: > > g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc > -DHAVE_CONFIG_H -Wall -W -Wshadow -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -m64 -mtune=nocona -D_GNU_SOURCE Array-s.cc -o pic/Array-s.o > g++: Internal error: Killed (program cc1plus) > Please submit a full bug report. > See for instructions. > {standard input}: Assembler messages: > {standard input}:141815: Warning: partial line at end of file ignored > > Originally, this happened on development and I filed a bug report > thinking this was a compiler problem. I got the following response to my > bug: > ------- Additional Comments From jakub at redhat.com 2005-07-05 17:27 EST > ------- > That means either that you or the kernel killed the compiler. > That does not mean there is a compiler bug. > A compiler bug would be if on reasonably large source the compiler ate > excessive amount of memory and OOM killer killed it. > So the question is: 1) how much physical memory and swap do you have > 2) run that command again and watch in top how much memory it is using > > After receiving this message, I tried building octave on FC4, and got > the same error on the same source file. The last time I built octave on > FC4 there were no problems. I don't really have any way of further > debugging this. Any ideas what's going on here? > OOM killer got it. swap wasn't mounting after I upgraded from FC3 to FC4 on the build server. now fixed. thanks, -sv From tcallawa at redhat.com Wed Jul 6 14:54:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 09:54:41 -0500 Subject: Request for Review: libstatgrab In-Reply-To: <42CB85C0.4000008@linux-kernel.at> References: <42CB85C0.4000008@linux-kernel.at> Message-ID: <1120661681.30349.130.camel@localhost.localdomain> On Wed, 2005-07-06 at 09:18 +0200, Oliver Falk wrote: > Hi! I'm still awaiting review for the libstatgrab package. > > libstatgrab: Make system statistics Review of libstatgrab: Bad: - BuildRoot not set using FE default. It should be: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - BuildRequires contains unnecessary items. Specifically: gcc, make, sed (see http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions ) - Requires contains non-existant package: ldconfig ldconfig is in glibc, but you don't need to put that as a requires either. - LGPL License is only correct for the libraries. Subpackage tools is under the GPL. The tools package should include the COPYING (GPL text). - COPYING.LGPL (LGPL License text) is not included in library package. - Typo in libstatgrab-tools description (should be "shipped" not "shiped") - Don't check for $RPM_BUILD_ROOT = / in %install or %clean. - You're overcomplicating the %post and %postun sections. Just use: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig - The devel package needs pkgconfig as a Requires. - Most of the groups used are invalid - The examples package is full of trash (.c, .o, .libs), and none of it is docs. - The fancy formatting confuses the crap out of rpmlint. When I remove it, I get better results. - You bzip2'd a ~50 line patch, resulting in an amazing savings of 1866 B. I have no idea why you did that, but I undid this, so that I could actually look at the patch. - In the statgrab-utils package, the binaries aren't getting stripped (and handled by the debuginfo package) because of their permissions. Do these binaries really need to be setuid to function? In my testing, these files do NOT need to be setuid to function correctly, so I went ahead and chmod'd 755 those files. I reworked the package spec extensively to resolve the above issues (the end result is attached to this email). With the new spec, the only rpmlint output is: statgrab-tools-0.11.1-2.i386.rpm: W: statgrab-tools devel-file-in-non-devel-package /usr/bin/statgrab-make-mrtg-config The devel-file-in-non-devel-package warning can be ignored. Good: - meets PackagingGuidelines, PackageNamingGuidelines. - source matches upstream, the licensing is correct. - spec name matches package name, spec is in Am. English and legible. - package successfully compiles and builds on x86 (FC4). - no missing BuildRequires, no locales to handle. - shared libraries have %post/%postun, static libs and .so are in -devel. - pkgconfig file is in -devel, has no extra Requires. - package is not relocatable - %clean section is fine. - No .la files packaged - Package is code not content. - macro use is consistent - no duplicate files - no unowned directories created If the new spec seems reasonable to you, then I'll give it my approval. Please note that I really don't intend to rewrite every spec I review, I did so in this case so that it could be a valuable learning experience. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! -------------- next part -------------- %define shortname statgrab Summary: Make system statistics Name: libstatgrab Version: 0.11.1 Release: 2%{?dist} Source0: ftp://ftp.i-scream.org/pub/i-scream/%{name}/%{name}-%{version}.tar.gz Patch0: %{name}.nochmod.patch License: LGPL Group: System Environment/Libraries Url: http://www.i-scream.org/%{name}/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: libtool glibc-devel ncurses-devel binutils %description Libstatgrab is a library that provides cross platform access to statistics about the system on which it's run. It's written in C and presents a selection of useful interfaces which can be used to access key system statistics. The current list of statistics includes CPU usage, memory utilisation, disk usage, process counts, network traffic, disk I/O, and more. The current list of platforms is Solaris 2.x, Linux, and FreeBSD 4.x/5.x. The aim is to extend this to include as many operating systems as possible. The package also includes a couple of useful tools. The first, saidar, provides a curses-based interface to viewing the current state of the system. The second, statgrab, gives a sysctl-style interface to the statistics gathered by libstatgrab. This extends the use of libstatgrab to people writing scripts or anything else that can't easily make C function calls. Included with statgrab is a script to generate an MRTG configuration file to use statgrab. %package -n %{shortname}-tools Summary: Tools from %{name} to monitoring the system Group: Applications/System %description -n %{shortname}-tools This package contains a few tools shiped with libstatgrab. Eg. A tool called saidar, which shows various system information like top, but - of course - OTHER informations. %package devel Summary: The development files from %{name} Group: Development/Libraries Requires: %{name} = %{version}-%{release} Requires: pkgconfig %description devel This package contains header files and man pages for those use to develop libstatgrab based applications. %package examples Summary: The example files from %{name} Group: Development/Tools Requires: %{name} = %{version}-%{release} %description examples This package contains various examples used to show how to develop libstatgrab based applications. %prep %setup -q %patch0 -p0 %build %configure --with-ncurses make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT cd examples/.libs install -m 755 cpu_usage disk_traffic load_stats network_iface_stats \ network_traffic os_info page_stats process_snapshot \ process_stats user_list vm_stats $RPM_BUILD_ROOT%{_bindir} chmod 755 $RPM_BUILD_ROOT%{_bindir}/statgrab-make-mrtg-config chmod 755 $RPM_BUILD_ROOT%{_bindir}/saidar chmod 755 $RPM_BUILD_ROOT%{_bindir}/statgrab %clean rm -rf $RPM_BUILD_ROOT %post -p /sbin/ldconfig %postun -p /sbin/ldconfig %files -n %shortname-tools %defattr(-,root,root) %doc COPYING %{_bindir}/saidar %{_bindir}/statgrab %{_bindir}/statgrab-make-mrtg-config %{_bindir}/statgrab-make-mrtg-index %{_mandir}/*/statgrab* %files %defattr(-,root,root) %doc AUTHORS INSTALL README ChangeLog NEWS COPYING.LGPL %{_libdir}/*.so.* %files devel %defattr(-,root,root) %{_libdir}/*.so %{_libdir}/*.a %{_libdir}/*.la %{_includedir}/*.h %{_libdir}/pkgconfig/%name.pc %{_mandir}/*/sg_* %files examples %defattr(-,root,root) %{_bindir}/cpu_usage %{_bindir}/disk_traffic %{_bindir}/load_stats %{_bindir}/network_iface_stats %{_bindir}/network_traffic %{_bindir}/os_info %{_bindir}/page_stats %{_bindir}/process_snapshot %{_bindir}/process_stats %{_bindir}/user_list %{_bindir}/vm_stats %changelog * Wed Jul 6 2005 Tom "spot" Callaway 0.11.1-2 - a lot of fixes for Fedora Extras * Thu May 19 2005 Oliver Falk - 0.11.1-1.1 - Specfile cleanup * Sun Apr 03 2005 Oliver Falk - 0.11.1-1 - Update * Fri Mar 25 2005 Oliver Falk - 0.11-2.1 - Fix rpmlint warnings * Tue Feb 15 2005 Oliver Falk - 0.11-2 - Don't require coreutils. They are normally installed on Fedora, but not available on RH 8, where the tools are usually also installed. Yes, rebuilding with nodeps would also do it, but it's not fine... * Tue Feb 15 2005 Oliver Falk - 0.11-1 - Initial build for Fedora Core From tcallawa at redhat.com Wed Jul 6 15:00:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 10:00:45 -0500 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <1120657242.30349.95.camel@localhost.localdomain> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> <49e94b51050706063078650c94@mail.gmail.com> <1120657242.30349.95.camel@localhost.localdomain> Message-ID: <1120662045.30349.132.camel@localhost.localdomain> On Wed, 2005-07-06 at 08:40 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 15:30 +0200, P Linnell wrote: > > > Not intended to do that... This is only a one time case. As several people have pointed out to me in private, Phil is pretty much giving up his Fedora packages for other people to take over. P, would you be interested in taking maintainership of the scribus packages? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From laroche at redhat.com Wed Jul 6 15:15:37 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 6 Jul 2005 17:15:37 +0200 Subject: New package: icmpdn In-Reply-To: <28626.192.54.193.35.1120656606.squirrel@rousalka.dyndns.org> References: <1119962800.15326.39.camel@pc7.dolda2000.com> <42C151D4.9060800@linux-kernel.at> <1119968531.15326.61.camel@pc7.dolda2000.com> <28626.192.54.193.35.1120656606.squirrel@rousalka.dyndns.org> Message-ID: <20050706151537.GA6177@dudweiler.stuttgart.redhat.com> On Wed, Jul 06, 2005 at 03:30:06PM +0200, Nicolas Mailhot wrote: > > On Mar 28 juin 2005 16:22, Fredrik Tolf wrote: > = > >> * Strange characters show up in %description: ???????? (after icmpdnd, > >> idnlookup, libnss_icmp.so.2) in firefox; In vim: ??~@~S > > > > Hm. It seems that Oron Peled copied my homepage directly into the README > > and specfile when he created them, so those are probably en-dashes in > > UTF-8. I never noticed, since all my systems handle UTF-8 correctly. > > > > I might as well fix it (dashes and en-dashes look the same in terminal > > fonts anyway), but is there anything wrong with using UTF-8 in > > specfiles? > > As long as it's valid UTF-8 just do everyone a favour and keep the UTF-8 > characters. RHL/FC has decided long ago to force UTF-8 adoption because > waiting for everyone not affected by ASCII problems to make the jump was > irrealistic. > > And yes it will break some utilities. We want them to break so they are > fixed someday. And you do need full UTF-8 in specs at least for people > names, because it's plain rude to force humans to mangle their names just > to accomodate the laziness of people who happen not to use more than 128 > characters in their everyday life. Nearly all packages in Fedora Core and Fedora Extras now have valid utf-8 content for the description and the changelog data. greetings, Florian La Roche From rc040203 at freenet.de Wed Jul 6 15:15:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jul 2005 17:15:26 +0200 Subject: Request for Review: libstatgrab In-Reply-To: <1120661681.30349.130.camel@localhost.localdomain> References: <42CB85C0.4000008@linux-kernel.at> <1120661681.30349.130.camel@localhost.localdomain> Message-ID: <1120662926.30532.134.camel@mccallum.corsepiu.local> On Wed, 2005-07-06 at 09:54 -0500, Tom 'spot' Callaway wrote: > BuildRequires: libtool glibc-devel ncurses-devel binutils ??? gcc is in the default set of packages, which means binutils and glibc-devel also are. Ralf From tcallawa at redhat.com Wed Jul 6 15:21:57 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 10:21:57 -0500 Subject: Request for Review: libstatgrab In-Reply-To: <1120662926.30532.134.camel@mccallum.corsepiu.local> References: <42CB85C0.4000008@linux-kernel.at> <1120661681.30349.130.camel@localhost.localdomain> <1120662926.30532.134.camel@mccallum.corsepiu.local> Message-ID: <1120663317.30349.136.camel@localhost.localdomain> On Wed, 2005-07-06 at 17:15 +0200, Ralf Corsepius wrote: > On Wed, 2005-07-06 at 09:54 -0500, Tom 'spot' Callaway wrote: > > > BuildRequires: libtool glibc-devel ncurses-devel binutils > > ??? gcc is in the default set of packages, which means binutils and > glibc-devel also are. Yeah, good point. Also, I realized that there might be value in including the .c files in examples/ as %doc. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From orion at cora.nwra.com Wed Jul 6 15:30:47 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jul 2005 09:30:47 -0600 Subject: Request for review: pytz and python-dateutil In-Reply-To: References: <42CAF271.50401@cora.nwra.com> Message-ID: <42CBF927.9010305@cora.nwra.com> Jos? Matos wrote: > Orion Poplawski wrote: > > Hi, > > >>I'm attempting to shift my python-matplotlib package to use upstream >>versions of pytz and dateutil. It bundles a version of each with it, >>but will not install if already present. So, it seems best to provide >>official versions of pytz and python-dateutil and have python-matplotlib >>require these to be present at build. > > > Last friday I sent a message to matplot-users list asking for the author > opinion on this subject. In one of the replies John Hunter, matplotlib > maintainer, said that matplotlib tar ball has several others python modules > inside: > > - agg > - pyparsing > - pycxx > > I will review later both pytz and python-dateutil packages. > Yeah, matplotlib is one big mess of a bunch of packages smashed together. At least with pytz and datetutil though, setup.py detects their presence and does not install if present. This was actually causing me grief when I tried to rebuild my python-matplotlib rpm with a version already installed. This is what motivated me to explicitly require pytz and python-dateutil - to obtain reproducible builds. agg, pyparsing, and pycxx are more tightly integrated, install in the matplotlib directory, and are referred to like: from matplotlib.pyparsing import Literal, Word, OneOrMore, ZeroOrMore, \ Combine, Group, Optional, Forward, NotAny, alphas, nums, alphanums, \ StringStart, StringEnd, ParseException (i.e. in the matplotlib namespace). I personally am not interested in doing the work of splitting matplotlib up, though I think the upstream project should do so. All this bundling is just a PITA in my opinion. There is similar issues with basemap, a matplotlib toolkit that I want to package. It bundles a version of PROJ.4. The maintainer though warned me against using an external PROJ.4 library. Again, it installs in its own space, so I don't have a big issue with it, but it strikes me as against the whole point of having common libraries. Other opinions on this welcomed, and I'm happy to go with whatever consensus develops. - Orion -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From oliver at linux-kernel.at Wed Jul 6 15:44:33 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 06 Jul 2005 17:44:33 +0200 Subject: Request for Review: libstatgrab In-Reply-To: <1120661681.30349.130.camel@localhost.localdomain> References: <42CB85C0.4000008@linux-kernel.at> <1120661681.30349.130.camel@localhost.localdomain> Message-ID: <42CBFC61.5030800@linux-kernel.at> Hi Spot! On 07/06/2005 04:54 PM, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 09:18 +0200, Oliver Falk wrote: > >>Hi! I'm still awaiting review for the libstatgrab package. >> >>libstatgrab: Make system statistics > > > Review of libstatgrab: > > Bad: > > - BuildRoot not set using FE default. It should be: > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > - BuildRequires contains unnecessary items. Specifically: > gcc, make, sed (see > http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions ) > - Requires contains non-existant package: ldconfig > ldconfig is in glibc, but you don't need to put that as a requires > either. > - LGPL License is only correct for the libraries. Subpackage tools is > under the GPL. The tools package should include the COPYING (GPL > text). > - COPYING.LGPL (LGPL License text) is not included in library package. > - Typo in libstatgrab-tools description (should be "shipped" not > "shiped") > - Don't check for $RPM_BUILD_ROOT = / in %install or %clean. > - You're overcomplicating the %post and %postun sections. Just use: > %post -p /sbin/ldconfig > %postun -p /sbin/ldconfig > - The devel package needs pkgconfig as a Requires. > - Most of the groups used are invalid > - The examples package is full of trash (.c, .o, .libs), and none of it > is docs. > - The fancy formatting confuses the crap out of rpmlint. When I remove > it, I get better results. > - You bzip2'd a ~50 line patch, resulting in an amazing savings of 1866 > B. I have no idea why you did that, but I undid this, so that I could > actually look at the patch. > - In the statgrab-utils package, the binaries aren't getting stripped > (and handled by the debuginfo package) because of their permissions. > Do these binaries really need to be setuid to function? In my > testing, these files do NOT need to be setuid to function correctly, > so I went ahead and chmod'd 755 those files. > > I reworked the package spec extensively to resolve the above issues (the > end result is attached to this email). > > With the new spec, the only rpmlint output is: > statgrab-tools-0.11.1-2.i386.rpm: > W: statgrab-tools > devel-file-in-non-devel-package /usr/bin/statgrab-make-mrtg-config > > The devel-file-in-non-devel-package warning can be ignored. > > Good: > > - meets PackagingGuidelines, PackageNamingGuidelines. > - source matches upstream, the licensing is correct. > - spec name matches package name, spec is in Am. English and legible. > - package successfully compiles and builds on x86 (FC4). > - no missing BuildRequires, no locales to handle. > - shared libraries have %post/%postun, static libs and .so are in > -devel. > - pkgconfig file is in -devel, has no extra Requires. > - package is not relocatable > - %clean section is fine. > - No .la files packaged > - Package is code not content. > - macro use is consistent > - no duplicate files > - no unowned directories created > > If the new spec seems reasonable to you, then I'll give it my approval. > > Please note that I really don't intend to rewrite every spec I review, I > did so in this case so that it could be a valuable learning experience. But thanks a lot for rewriting it.... I'm currently a bit busy so it helped a lot!!! Just recreated the srpm and uploaded the spec: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libstatgrab I just changed a few identation things, nothing relevant. You may have a look at it again and approve it now. Best, Oliver From qspencer at ieee.org Wed Jul 6 16:01:56 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 06 Jul 2005 11:01:56 -0500 Subject: Request for review: ncview In-Reply-To: <1120613945.10305.232.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> Message-ID: <42CC0074.1070602@ieee.org> Ed Hill wrote: >On Tue, 2005-07-05 at 19:15 -0500, Tom 'spot' Callaway wrote: > > >>> - it conflicts with a different ncview package that I'd >>> like to separately submit to extras which actually >>> *does* work >>> >>> >>The new package doesn't conflict with Ed's other ncview package. >> >> > > >Hi folks, > >In addition to Spot's freshly polished opendap version, I'd like to >submit this ncview package for review: > > http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-2.src.rpm > http://mitgcm.org/eh3/fedora_misc/ncview.spec > >It compiles and works for me on FC3 and FC4. > >Ncview is a great little interactive utility for creating 1D/2D plots of >numerical data stored in netCDF files. It can do animated loops and can >write output to files which, when combined with simple shell/ImageMagick >scripts, is a very convenient way to create simple "movies". > >Please point out any blockers and I'll fix them ASAP. > >thank you, >Ed > > OK, the packages builds and installs fine for me on FC3 (don't have a FC4 system handy at the moment). The only rpmlint error I got was something about non-binary stuff in /usr/lib. Investigating further, I discovered that /usr/lib contains _only_ non-binary files, all of which look like the sort of thing you might normally put in /usr/share. Was this the intention of the original author? It also looks like maybe you were trying to remove some of this with these lines in the spec: rm -f ${RPM_BUILD_ROOT}%{_libdir}/*.ncmap rm -f ${RPM_BUILD_ROOT}%{_libdir}/ncoverlay* However, these lines don't appear to do anything, as the files are all located in /usr/lib/ncview/* rather than /usr/lib/*, and the ncoverlay* files are actually nc_overlay*. If you don't want these in the package, you could also use %exclude %{_libdir}/ncview* in the %files section. (Or maybe NCVIEW_LIB_DIR=/dev/null in the makeinstall command? :) ) -Quentin From orion at cora.nwra.com Wed Jul 6 16:22:59 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jul 2005 10:22:59 -0600 Subject: Request for review: ncview In-Reply-To: <1120613945.10305.232.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> Message-ID: <42CC0563.2090505@cora.nwra.com> Ed Hill wrote: > > Hi folks, > > In addition to Spot's freshly polished opendap version, I'd like to > submit this ncview package for review: > > http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-2.src.rpm > http://mitgcm.org/eh3/fedora_misc/ncview.spec > Compiles and installs/runs/removes fine for me on fc4, other than Quentin's comments about /usr/lib. Other: - COPYING not included in %doc. - no rm -rf $RPM_BUILD_ROOT in %install No blockers though. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ed at eh3.com Wed Jul 6 16:42:43 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 06 Jul 2005 12:42:43 -0400 Subject: Request for review: ncview In-Reply-To: <42CC0074.1070602@ieee.org> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> Message-ID: <1120668164.10305.287.camel@ernie> On Wed, 2005-07-06 at 11:01 -0500, Quentin Spencer wrote: > > OK, the packages builds and installs fine for me on FC3 (don't have a > FC4 system handy at the moment). The only rpmlint error I got was > something about non-binary stuff in /usr/lib. Investigating further, I > discovered that /usr/lib contains _only_ non-binary files, all of which > look like the sort of thing you might normally put in /usr/share. Was > this the intention of the original author? It also looks like maybe you > were trying to remove some of this with these lines in the spec: > rm -f ${RPM_BUILD_ROOT}%{_libdir}/*.ncmap > rm -f ${RPM_BUILD_ROOT}%{_libdir}/ncoverlay* > > However, these lines don't appear to do anything, as the files are all > located in /usr/lib/ncview/* rather than /usr/lib/*, and the ncoverlay* > files are actually nc_overlay*. If you don't want these in the package, > you could also use %exclude %{_libdir}/ncview* in the %files section. > (Or maybe NCVIEW_LIB_DIR=/dev/null in the makeinstall command? :) ) Hi Quentin & Orion, Thank you both for the reviews! I've done the following: - with the one exception described below, moved all of the data files into /usr/share/ncview - deleted the useless rm lines - added COPYING to %doc - added xorg-x11 Requires and xorg-x11-devel BuildRequires and heres the updated SRPM and spec: http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-3.src.rpm http://mitgcm.org/eh3/fedora_misc/ncview.spec The exception noted above is /usr/lib/X11/app-defaults/Ncview which I'm fairly certain is in an acceptable location since its owned by the Required xorg-x11 and seems to be there for just that purpose. But if it violates one of the Fedora packaging guidelines, please let me know and I'll happily move it. ;-) thanks again! Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From qspencer at ieee.org Wed Jul 6 16:55:23 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 06 Jul 2005 11:55:23 -0500 Subject: Request for review: ncview In-Reply-To: <1120668164.10305.287.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> <1120668164.10305.287.camel@ernie> Message-ID: <42CC0CFB.1040606@ieee.org> Ed Hill wrote: >On Wed, 2005-07-06 at 11:01 -0500, Quentin Spencer wrote: > > >>OK, the packages builds and installs fine for me on FC3 (don't have a >>FC4 system handy at the moment). The only rpmlint error I got was >>something about non-binary stuff in /usr/lib. Investigating further, I >>discovered that /usr/lib contains _only_ non-binary files, all of which >>look like the sort of thing you might normally put in /usr/share. Was >>this the intention of the original author? It also looks like maybe you >>were trying to remove some of this with these lines in the spec: >>rm -f ${RPM_BUILD_ROOT}%{_libdir}/*.ncmap >>rm -f ${RPM_BUILD_ROOT}%{_libdir}/ncoverlay* >> >>However, these lines don't appear to do anything, as the files are all >>located in /usr/lib/ncview/* rather than /usr/lib/*, and the ncoverlay* >>files are actually nc_overlay*. If you don't want these in the package, >>you could also use %exclude %{_libdir}/ncview* in the %files section. >>(Or maybe NCVIEW_LIB_DIR=/dev/null in the makeinstall command? :) ) >> >> > > >Hi Quentin & Orion, > >Thank you both for the reviews! > >I've done the following: > > - with the one exception described below, moved all of the > data files into /usr/share/ncview > - deleted the useless rm lines > - added COPYING to %doc > - added xorg-x11 Requires and xorg-x11-devel BuildRequires > >and heres the updated SRPM and spec: > > http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-3.src.rpm > http://mitgcm.org/eh3/fedora_misc/ncview.spec > >The exception noted above is /usr/lib/X11/app-defaults/Ncview which I'm >fairly certain is in an acceptable location since its owned by the >Required xorg-x11 and seems to be there for just that purpose. But if >it violates one of the Fedora packaging guidelines, please let me know >and I'll happily move it. ;-) > > Yes, this still gives that rpmlint error, but I think you're right. Putting everything else in _datadir makes more sense to me. Consider it approved. -Quentin From orion at cora.nwra.com Wed Jul 6 17:10:20 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jul 2005 11:10:20 -0600 Subject: Request for review: ncview In-Reply-To: <1120668164.10305.287.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> <1120668164.10305.287.camel@ernie> Message-ID: <42CC107C.3020409@cora.nwra.com> Ed Hill wrote: > The exception noted above is /usr/lib/X11/app-defaults/Ncview which I'm > fairly certain is in an acceptable location since its owned by the > Required xorg-x11 and seems to be there for just that purpose. But if > it violates one of the Fedora packaging guidelines, please let me know > and I'll happily move it. ;-) > Yeah, this is an rpmlint bug since that is the standard place for X application resource files. Looks good. I'll let our users know about it as soon as it comes down the pipe. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugs.michael at gmx.net Wed Jul 6 17:14:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 19:14:50 +0200 Subject: Request for review: ncview In-Reply-To: <1120668164.10305.287.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> <1120668164.10305.287.camel@ernie> Message-ID: <20050706191450.49c1e13e.bugs.michael@gmx.net> On Wed, 06 Jul 2005 12:42:43 -0400, Ed Hill wrote: > http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-3.src.rpm > http://mitgcm.org/eh3/fedora_misc/ncview.spec It ignores $RPM_OPT_FLAGS. It will fail to build on x86_64, because it hardcodes /usr/lib for NetCDF. It contains an executable manual page. It prints a security relevant warning, which ought to be examined closer: /home/misc5/tmp/rpm/BUILD/ncview-1.92e/do_print.c:91: warning: the use of `tmpna m' is dangerous, better use `mkstemp' > %build > cp Makefile.in Makefile.in.OLD > cat Makefile.in | What does that do? > %install > export XAPPLRESDIR="${RPM_BUILD_ROOT}%{_libdir}/X11/app-defaults" "rm -rf $RPM_BUILD_ROOT" is missing between those lines. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 2.14 2.14 1.56 From qspencer at ieee.org Wed Jul 6 17:20:45 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 06 Jul 2005 12:20:45 -0500 Subject: More build problems on x86_64 In-Reply-To: <1120660879.26751.31.camel@cutter> References: <42CBE8A1.2020709@ieee.org> <1120660879.26751.31.camel@cutter> Message-ID: <42CC12ED.9090904@ieee.org> seth vidal wrote: >On Wed, 2005-07-06 at 09:20 -0500, Quentin Spencer wrote: > > >>I'm getting the following error building octave on x86_64: >> >>g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc >>-DHAVE_CONFIG_H -Wall -W -Wshadow -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 >>-fexceptions -m64 -mtune=nocona -D_GNU_SOURCE Array-s.cc -o pic/Array-s.o >>g++: Internal error: Killed (program cc1plus) >>Please submit a full bug report. >>See for instructions. >>{standard input}: Assembler messages: >>{standard input}:141815: Warning: partial line at end of file ignored >> >>Originally, this happened on development and I filed a bug report >>thinking this was a compiler problem. I got the following response to my >>bug: >>------- Additional Comments From jakub at redhat.com 2005-07-05 17:27 EST >>------- >>That means either that you or the kernel killed the compiler. >>That does not mean there is a compiler bug. >>A compiler bug would be if on reasonably large source the compiler ate >>excessive amount of memory and OOM killer killed it. >>So the question is: 1) how much physical memory and swap do you have >>2) run that command again and watch in top how much memory it is using >> >>After receiving this message, I tried building octave on FC4, and got >>the same error on the same source file. The last time I built octave on >>FC4 there were no problems. I don't really have any way of further >>debugging this. Any ideas what's going on here? >> >> >> > >OOM killer got it. > >swap wasn't mounting after I upgraded from FC3 to FC4 on the build >server. > >now fixed. > > Thanks. This indeed does appear to fix the problem. However, my resubmitted octave build just failed due to timeout (with a completed set of RPMs). I've had this problem before, but not for a while. Is this likely to happen again if I resubmit for building? Is this just random, or is there something else going on that's causing this? -Quentin From andreas at bawue.net Wed Jul 6 17:46:11 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 6 Jul 2005 19:46:11 +0200 (CEST) Subject: Request for Review dd_rescue/ddrescue/dd_rhelp Message-ID: Hello, Just a short recap of the current situation: There exist two fault tollerant dd solutions. One is named dd_rescue, the other is named ddrescue. Both have their pros and cons. dd_rescue together with dd_rhelp (a bash helper script) looks a bit more advanced then the GNU ddrescue, but this is my personal opinion. Problem was that there is currently a ddrescue package in the fedora-extras tree, which does package dd_rescue. This is a bit confusing, as there are people who'd like ddrescue as well. My suggestion to solve this mess is to include three packages, ddrescue, dd_rescue and dd_rhelp with correct epoch and conflict tags to fix the naming mess. Could someone please review these packages? http://home.bawue.de/~ixs/dd_rescue/ http://home.bawue.de/~ixs/dd_rhelp/ http://home.bawue.de/~ixs/ddrescue/ thanks, andreas From Jochen at herr-schmitt.de Wed Jul 6 17:49:05 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 06 Jul 2005 19:49:05 +0200 Subject: Request for review: koffice In-Reply-To: <42CAFFD8.2020101@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> Message-ID: <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 05 Jul 2005 23:47:04 +0200, you wrote: >Ok, I have done some work on koffice again... hence look here: >http://fedora.lowlatency.de/review/ I have found a bug. After I have built na installed the packages, I found out, that the menu entries was displayed twice in the menu. I think you should delete all files on /usr/share/applnk/Office. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQswZoE9gByurcX4MEQInYACfZNIorocUkJQlIJs/4zQwwZdzVtkAoM4r siPRNVVSxj6hR59FfAREZ1zY =4I6k -----END PGP SIGNATURE----- From bugs.michael at gmx.net Wed Jul 6 17:52:05 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jul 2005 19:52:05 +0200 Subject: Take 2: greek font packages In-Reply-To: <20050705113621.GB5157@gallagher.di.uoa.gr> References: <20050705113621.GB5157@gallagher.di.uoa.gr> Message-ID: <20050706195205.52a67cd7.bugs.michael@gmx.net> On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > The updated spec files, srpms and rpms for mgopen-fonts and > tetex-font-kerkis are in > http://gallagher.di.uoa.gr/any/rpms/ mgopen-fonts: Approved. Purely cosmetic would be these spelling-fixes ("license" is American English, "licence" is British English): --- mgopen-fonts.spec~ 2005-06-21 10:34:11.000000000 +0200 +++ mgopen-fonts.spec 2005-07-06 19:49:07.000000000 +0200 @@ -19,9 +19,9 @@ %description -The MgOpen fonts are a font family that includes latin and greek glyphs. -The fonts have been released under a liberal licence, similar to the -licence covering the Bitstream Vera fonts. +The MgOpen fonts are a font family that includes Latin and Greek glyphs. +The fonts have been released under a liberal license, similar to the +license covering the Bitstream Vera fonts. %prep You could correct or drop the version-release numbers in the spec %changelog. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 2.25 2.85 2.62 From andreas at bawue.net Wed Jul 6 17:54:08 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 6 Jul 2005 19:54:08 +0200 (CEST) Subject: Review still needed: barcode Message-ID: Hello, there's still a final review and approval needed for the gnu barcode package: %description Barcode is meant to solve most needs in barcode creation with a conventional printer. It can create printouts for the conventional product tagging standards: UPC-A, UPC-E, EAN-13, EAN-8, ISBN, as well as a few other formats. Ouput is generated as either Postscript or Encapsulated Postscript. I incorporated the earlier change-requests from the mailinglist into the latest release: Specfile: http://home.bawue.de/~ixs/barcode/barcode.spec SRPM: http://home.bawue.de/~ixs/barcode/barcode-0.98-4.src.rpm thanks, andreas From ed at eh3.com Wed Jul 6 18:08:09 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 06 Jul 2005 14:08:09 -0400 Subject: Request for review: ncview In-Reply-To: <20050706191450.49c1e13e.bugs.michael@gmx.net> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> <1120668164.10305.287.camel@ernie> <20050706191450.49c1e13e.bugs.michael@gmx.net> Message-ID: <1120673289.10305.297.camel@ernie> On Wed, 2005-07-06 at 19:14 +0200, Michael Schwendt wrote: > On Wed, 06 Jul 2005 12:42:43 -0400, Ed Hill wrote: > > > http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-3.src.rpm > > http://mitgcm.org/eh3/fedora_misc/ncview.spec > > It ignores $RPM_OPT_FLAGS. I think this is now fixed but please let me know if it needs work. > It will fail to build on x86_64, because it hardcodes /usr/lib for > NetCDF. Fixed. > It contains an executable manual page. Fixed. > It prints a security relevant warning, which ought to be examined > closer: > > /home/misc5/tmp/rpm/BUILD/ncview-1.92e/do_print.c:91: warning: the use of `tmpna > m' is dangerous, better use `mkstemp' I've written and added a patch that seems to do the right thing. > > %build > > cp Makefile.in Makefile.in.OLD > > cat Makefile.in | > > What does that do? Fixed by removal. > > %install > > export XAPPLRESDIR="${RPM_BUILD_ROOT}%{_libdir}/X11/app-defaults" > > "rm -rf $RPM_BUILD_ROOT" is missing between those lines. Fixed. Thank you for the review! Heres the updated version and please point out any remaining blockers: http://mitgcm.org/eh3/fedora_misc/ncview-1.92e-4.src.rpm http://mitgcm.org/eh3/fedora_misc/ncview.spec Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From rdieter at math.unl.edu Wed Jul 6 18:25:57 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Jul 2005 13:25:57 -0500 Subject: Request for review: koffice In-Reply-To: <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> Message-ID: Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 05 Jul 2005 23:47:04 +0200, you wrote: > > >>Ok, I have done some work on koffice again... hence look here: >>http://fedora.lowlatency.de/review/ > > > I have found a bug. After I have built na installed the packages, > I found out, that the menu entries was displayed twice in the > menu. > > I think you should delete all files on /usr/share/applnk/Office. Fix: whenever you use desktop-file-install use the --delete-original switch -- Rex From Fedora at TQMcube.com Wed Jul 6 19:12:37 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Wed, 06 Jul 2005 15:12:37 -0400 Subject: php-eaccelerator In-Reply-To: <200507022211.j62MB0Y5008594@mail.linux-kernel.at> References: <200507022211.j62MB0Y5008594@mail.linux-kernel.at> Message-ID: <1120677157.4619.89.camel@dch.TQMcube.com> Installing the rpm doesn't install the package. Indeed, the web interface, eaccelator.php, so indicates. I found encoder.php in /usr/share/doc/php-eaccelerator*. Simple enough to use to encode a site's php scripts but I cannot figure out where to go from there. Should the rpm create a service? Docs are not much help. Can anyone give me a quick boost? -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From Fedora at TQMcube.com Wed Jul 6 19:27:53 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Wed, 06 Jul 2005 15:27:53 -0400 Subject: php-eaccelerator In-Reply-To: <1120677157.4619.89.camel@dch.TQMcube.com> References: <200507022211.j62MB0Y5008594@mail.linux-kernel.at> <1120677157.4619.89.camel@dch.TQMcube.com> Message-ID: <1120678073.4619.90.camel@dch.TQMcube.com> On Wed, 2005-07-06 at 15:12 -0400, David Cary Hart wrote: > Installing the rpm doesn't install the package. Indeed, the web > interface, eaccelator.php, so indicates. I found encoder.php > in /usr/share/doc/php-eaccelerator*. Simple enough to use to encode a > site's php scripts but I cannot figure out where to go from there. > > Should the rpm create a service? Docs are not much help. Can anyone give > me a quick boost? Never mind. I simply had to restart httpd. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From fredrik at dolda2000.com Wed Jul 6 19:51:23 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Wed, 06 Jul 2005 21:51:23 +0200 Subject: New package: icmpdn In-Reply-To: <28626.192.54.193.35.1120656606.squirrel@rousalka.dyndns.org> References: <1119962800.15326.39.camel@pc7.dolda2000.com> <42C151D4.9060800@linux-kernel.at> <1119968531.15326.61.camel@pc7.dolda2000.com> <28626.192.54.193.35.1120656606.squirrel@rousalka.dyndns.org> Message-ID: <1120679483.14996.30.camel@pc7.dolda2000.com> On Wed, 2005-07-06 at 15:30 +0200, Nicolas Mailhot wrote: > On Mar 28 juin 2005 16:22, Fredrik Tolf wrote: > = > >> * Strange characters show up in %description: ???????? (after icmpdnd, > >> idnlookup, libnss_icmp.so.2) in firefox; In vim: ??~@~S > And yes it will break some utilities. We want them to break so they are > fixed someday. Hehe, you may want to begin by fixing the MUA you're using (SquirrelMail?), because it just broke those extended characters even further. ;-) Fredrik Tolf From steve at silug.org Wed Jul 6 20:03:56 2005 From: steve at silug.org (Steven Pritchard) Date: Wed, 6 Jul 2005 15:03:56 -0500 Subject: OpenGroupware? Message-ID: <20050706200356.GB29034@osiris.silug.org> Is anyone working on cleaning up OpenGroupware for Extras? If not, I will probably have to. (I have a client who wants it set up.) Of course, I'd rather just review someone else's work... ;-) 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 Nicolas.Mailhot at laPoste.net Wed Jul 6 20:25:27 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 06 Jul 2005 22:25:27 +0200 Subject: New package: icmpdn In-Reply-To: <1120679483.14996.30.camel@pc7.dolda2000.com> References: <1119962800.15326.39.camel@pc7.dolda2000.com> <42C151D4.9060800@linux-kernel.at> <1119968531.15326.61.camel@pc7.dolda2000.com> <28626.192.54.193.35.1120656606.squirrel@rousalka.dyndns.org> <1120679483.14996.30.camel@pc7.dolda2000.com> Message-ID: <1120681527.18405.23.camel@rousalka.dyndns.org> Le mercredi 06 juillet 2005 ? 21:51 +0200, Fredrik Tolf a ?crit : > On Wed, 2005-07-06 at 15:30 +0200, Nicolas Mailhot wrote: > > On Mar 28 juin 2005 16:22, Fredrik Tolf wrote: > > = > > >> * Strange characters show up in %description: ???????? (after icmpdnd, > > >> idnlookup, libnss_icmp.so.2) in firefox; In vim: ??~@~S > > And yes it will break some utilities. We want them to break so they are > > fixed someday. > > Hehe, you may want to begin by fixing the MUA you're using > (SquirrelMail?), because it just broke those extended characters even > further. ;-) T'was my thought too. But after all squirrelmail is just a webmail, not a full-fetured MUA. I need to find some time to create a good bug report. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fredrik at dolda2000.com Wed Jul 6 20:44:27 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Wed, 06 Jul 2005 22:44:27 +0200 Subject: Request for review: icmpdn Message-ID: <1120682668.14996.40.camel@pc7.dolda2000.com> Hi! I've fixed all the initial issues that were pointed out, so I'd appreciate if someone would review this package now. %description Since the Linux kernel does not support the ICMP host name facilities as described in RFC 1788, I wrote a simple implementation in user-space. It comprises three parts: * icmpdnd - The ICMP Domain Name daemon, which listens to ICMP domain name requests and replies to them. * idnlookup - A user utility to query a host for its host name over ICMP. Like ping and all other utilities that use ICMP, it needs to be installed SUID root. * libnss_icmp.so.2 - A glibc NSS module, which uses idnlookup to perform queries for the gethostbyaddr function. Spec and SRPM: Also, I'd appreciate if someone would CVS-sponsor it, since I have no such account. Does anyone have a link (to the wiki?) with the proper procedures for maintaining a package in FE? Thanks, Fredrik Tolf From mrdocs at gmail.com Wed Jul 6 21:26:44 2005 From: mrdocs at gmail.com (P Linnell) Date: Wed, 6 Jul 2005 23:26:44 +0200 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <1120662045.30349.132.camel@localhost.localdomain> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> <49e94b51050706063078650c94@mail.gmail.com> <1120657242.30349.95.camel@localhost.localdomain> <1120662045.30349.132.camel@localhost.localdomain> Message-ID: <49e94b510507061426597c9206@mail.gmail.com> On 7/6/05, Tom 'spot' Callaway wrote: > On Wed, 2005-07-06 at 08:40 -0500, Tom 'spot' Callaway wrote: > > On Wed, 2005-07-06 at 15:30 +0200, P Linnell wrote: > > > > > Not intended to do that... This is only a one time case. > > As several people have pointed out to me in private, Phil is pretty much > giving up his Fedora packages for other people to take over. P, would > you be interested in taking maintainership of the scribus packages? > > ~spot > -- > Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > Hi, In the absence of Phil, I will, but honestly, I cannot see taking it over permanently. It is simply a time factor for me. I would be glad to work with anyone else on Scribus and Inkscape in particular, as well Cordially, Peter From ville.skytta at iki.fi Wed Jul 6 21:41:49 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 07 Jul 2005 00:41:49 +0300 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> Message-ID: <1120686109.6862.436.camel@localhost.localdomain> On Wed, 2005-07-06 at 13:25 -0500, Rex Dieter wrote: > Fix: whenever you use > desktop-file-install > use the > --delete-original > switch ...except when the .desktop file in question is included in the package as SourceX, or deleting it would break --short-circuit builds. From compton at pcompton.com Wed Jul 6 21:41:46 2005 From: compton at pcompton.com (Phillip Compton) Date: Wed, 06 Jul 2005 17:41:46 -0400 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <49e94b510507061426597c9206@mail.gmail.com> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> <49e94b51050706063078650c94@mail.gmail.com> <1120657242.30349.95.camel@localhost.localdomain> <1120662045.30349.132.camel@localhost.localdomain> <49e94b510507061426597c9206@mail.gmail.com> Message-ID: <1120686106.14050.15.camel@PHILC-FC4> On Wed, 2005-07-06 at 23:26 +0200, P Linnell wrote: > On 7/6/05, Tom 'spot' Callaway wrote: > > As several people have pointed out to me in private, Phil is pretty much > > giving up his Fedora packages for other people to take over. P, would > > you be interested in taking maintainership of the scribus packages? > > > Hi, > > In the absence of Phil, I will, but honestly, I cannot see taking it > over permanently. > > It is simply a time factor for me. I would be glad to work with anyone > else on Scribus and Inkscape in particular, as well In a few weeks I should have time to start contributing to Fedora again, but in the mean time I do appreciate anyone willing to help out with the packages I maintain, and if they fancy, take over maintainer-ship of them. Peter, if no one steps in to take over Scribus and Inkscape, I will return to maintaining them when I start contributing again. Phil ps. Thank you to everyone who has stepped in to pick up the ball I dropped. It has been much appreciated. From mrdocs at gmail.com Wed Jul 6 22:24:26 2005 From: mrdocs at gmail.com (P Linnell) Date: Thu, 7 Jul 2005 00:24:26 +0200 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <1120686106.14050.15.camel@PHILC-FC4> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> <49e94b51050706063078650c94@mail.gmail.com> <1120657242.30349.95.camel@localhost.localdomain> <1120662045.30349.132.camel@localhost.localdomain> <49e94b510507061426597c9206@mail.gmail.com> <1120686106.14050.15.camel@PHILC-FC4> Message-ID: <49e94b5105070615241d46bd7c@mail.gmail.com> On 7/6/05, Phillip Compton wrote: > On Wed, 2005-07-06 at 23:26 +0200, P Linnell wrote: > > On 7/6/05, Tom 'spot' Callaway wrote: > > > As several people have pointed out to me in private, Phil is pretty much > > > giving up his Fedora packages for other people to take over. P, would > > > you be interested in taking maintainership of the scribus packages? > > > > > Hi, > > > > In the absence of Phil, I will, but honestly, I cannot see taking it > > over permanently. > > > > It is simply a time factor for me. I would be glad to work with anyone > > else on Scribus and Inkscape in particular, as well > > In a few weeks I should have time to start contributing to Fedora again, > but in the mean time I do appreciate anyone willing to help out with the > packages I maintain, and if they fancy, take over maintainer-ship of > them. > > Peter, if no one steps in to take over Scribus and Inkscape, I will > return to maintaining them when I start contributing again. > > > Phil > > > ps. Thank you to everyone who has stepped in to pick up the ball I > dropped. It has been much appreciated. > > Thanks for the update Phil. I know an Inkscape 0.42 is immiment too, so I'll look after this too. If someone could look over Scribus and let me know if it passes muster that would be great. I do not have CVS access, nor the contributor stuff sorted yet. Peter From tcallawa at redhat.com Wed Jul 6 23:38:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Jul 2005 18:38:51 -0500 Subject: Updated Scribus 1.2.2.1 for FC In-Reply-To: <49e94b5105070615241d46bd7c@mail.gmail.com> References: <20050706081928.CBA79737E8@hormel.redhat.com> <49e94b5105070606012268b6ed@mail.gmail.com> <1120655868.30349.86.camel@localhost.localdomain> <49e94b51050706063078650c94@mail.gmail.com> <1120657242.30349.95.camel@localhost.localdomain> <1120662045.30349.132.camel@localhost.localdomain> <49e94b510507061426597c9206@mail.gmail.com> <1120686106.14050.15.camel@PHILC-FC4> <49e94b5105070615241d46bd7c@mail.gmail.com> Message-ID: <1120693131.9303.9.camel@localhost.localdomain> On Thu, 2005-07-07 at 00:24 +0200, P Linnell wrote: > If someone could look over Scribus and let me know if it passes muster > that would be great. I do not have CVS access, nor the contributor > stuff sorted yet. Scribus looks fine. I went ahead and committed your changes, and triggered a build for FC-4. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From lmacken at redhat.com Thu Jul 7 02:59:47 2005 From: lmacken at redhat.com (Luke Macken) Date: Wed, 6 Jul 2005 22:59:47 -0400 Subject: Request for Review: naim In-Reply-To: <20050705152955.GA13111@tomservo.boston.redhat.com> References: <20050705152955.GA13111@tomservo.boston.redhat.com> Message-ID: <20050707025947.GA12388@tomservo.boston.redhat.com> On Tue, Jul 05, 2005 at 11:29:55AM -0400, Luke Macken wrote: | naim is a console client for AOL Instant Messenger (AIM), AOL I Seek You | (ICQ), Internet Relay Chat (IRC), and The lily CMC. | | http://people.redhat.com/lmacken/naim.spec | http://people.redhat.com/lmacken/naim-0.11.7.3.1-1.src.rpm In order to please rpmlint, I made a devel subpackage for the naim and firetalk libraries that are installed as well. Now rpmlint only spits out a warning because there is no documentation for the devel package. Can someone give the spec a once-over before I import it to CVS ? Thanks, luke From buildsys at fedoraproject.org Thu Jul 7 04:47:54 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 7 Jul 2005 00:47:54 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050707044754.901348E48@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 12 R-2.1.1-2.fc3 ebtables-2.0.6-6.fc3 ebtables-2.0.6-7.fc3 fish-1.11.1-10.fc3 gambas-1.0.6-3.fc3 hdf5-1.6.4-4.fc3 konversation-0.18-4.fc3 mod_suphp-0.5.2-7.fc3 most-4.10.1-1.fc3 perl-Time-modules-2003.1126-2.fc3 scim-anthy-0.5.0-1.fc3 xbase-2.0.0-2.fc3 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 Thu Jul 7 05:03:09 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 7 Jul 2005 01:03:09 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050707050309.8326A8E48@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 23 R-2.1.1-2.fc4 TeXmacs-1.0.5.5-1.fc4 ebtables-2.0.6-7.fc4 fish-1.11.1-10.fc4 gaim-guifications-2.10-4.fc4 gambas-1.0.6-3.fc4 global-4.8.6-1.fc4 gnome-applet-sensors-1.0-1.fc4 gramps-2.0.5-1.fc4 hdf5-1.6.4-4.fc4 konversation-0.18-4.fc4 libpqxx-2.5.4-4.fc4 mod_suphp-0.5.2-6.fc4 mod_suphp-0.5.2-7.fc4 most-4.10.1-1.fc4 perl-Time-modules-2003.1126-2.fc4 qgo-1.0.2-1.fc4 scribus-1.2.2.1-1 scrub-1.6-3.fc4 tetex-font-cm-lgc-0.5-2.fc4 tkcvs-7.2.3-1 wv2-0.2.2-5.fc4 xbase-2.0.0-2.fc4 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 Thu Jul 7 05:13:55 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 7 Jul 2005 01:13:55 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050707051355.F0B408E48@extras64.linux.duke.edu> Packages built and released for Fedora Extras development: 19 cln-1.1.9-8.fc5 epiphany-extensions-1.7.1-2 global-4.8.6-1.fc5 gnome-applet-sensors-1.0-2.fc5 gramps-2.0.5-1.fc5 hdf5-1.6.4-4.fc5 konversation-0.18-4.fc5 libassuan-0.6.10-2.fc5 mod_suphp-0.5.2-6.fc5 mod_suphp-0.5.2-7.fc5 most-4.10.1-1.fc5 perl-Module-Build-0.2611-1.fc5 perl-Time-modules-2003.1126-2.fc5 perl-Tree-DAG_Node-1.05-2.fc5 qgo-1.0.2-1.fc5 sylpheed-2.0.0-0.4.beta4 tetex-font-cm-lgc-0.5-2.fc5 tkcvs-7.2.3-2 wv2-0.2.2-5.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From oliver at linux-kernel.at Thu Jul 7 07:22:16 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 07 Jul 2005 09:22:16 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120682668.14996.40.camel@pc7.dolda2000.com> References: <1120682668.14996.40.camel@pc7.dolda2000.com> Message-ID: <42CCD828.4090609@linux-kernel.at> Hi Fredrik! On 07/06/2005 10:44 PM, Fredrik Tolf wrote: > I've fixed all the initial issues that were pointed out, so I'd > appreciate if someone would review this package now. > > %description > Since the Linux kernel does not support the ICMP host name facilities as > described in RFC 1788, I wrote a simple implementation in user-space. > It comprises three parts: > > * icmpdnd - The ICMP Domain Name daemon, which listens to ICMP > domain name requests and replies to them. > > * idnlookup - A user utility to query a host for its host name over > ICMP. Like ping and all other utilities that use ICMP, it needs to > be installed SUID root. > > * libnss_icmp.so.2 - A glibc NSS module, which uses idnlookup to > perform queries for the gethostbyaddr function. > > Spec and SRPM: > > Good: * package is named according to PackageNamingGuidelines * spec file name matches %{name} * License (GPL) is OK, COPYING is included in %doc * Spec file is in English * Sources match upstream * Package compiles and builds on x86 (FC4) * Package compiles and build with mock (FCdev, x86) * No need for -devel or -docs subpackage * %clean section exists * macro usage is constistent * package is code, not content * nothing in %doc affects runtime Bad: * license of libs is LGPL, but LGPL license is missing. Download a copy and included it in %doc. If you add this, I'm going to approve the package. > Also, I'd appreciate if someone would CVS-sponsor it, since I have no > such account. Does anyone have a link (to the wiki?) with the proper > procedures for maintaining a package in FE? Do you have requested an account allready? If not, please do so: https://admin.fedora.redhat.com/accounts/ Someone will then cvs-sponsor you... Not me, as I havn't the right to do so. However, in the meanwhile I can cvs-import the package for you, request CVSSync (http://fedoraproject.org/wiki/Extras/CVSSyncNeeded) for FC3, FC4 (any other?) and also request a bugzilla entry (http://fedoraproject.org/wiki/Extras/BugzillaAdmin) - if you want me to do so. If so, please create a bugzilla account - if you don't have one yet and let me know the mailaddress you used for register. Best, Oliver From wtogami at redhat.com Thu Jul 7 10:08:39 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Jul 2005 00:08:39 -1000 Subject: Take 2: greek font packages In-Reply-To: <20050706195205.52a67cd7.bugs.michael@gmx.net> References: <20050705113621.GB5157@gallagher.di.uoa.gr> <20050706195205.52a67cd7.bugs.michael@gmx.net> Message-ID: <42CCFF27.5050700@redhat.com> Michael Schwendt wrote: > On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > > >>The updated spec files, srpms and rpms for mgopen-fonts and >>tetex-font-kerkis are in >>http://gallagher.di.uoa.gr/any/rpms/ > > > mgopen-fonts: Approved. > Please follow the documented procedure which dictates that a message should be posted with subject "APPROVED: packagename" so that it can be easily found in searches. Warren Togami wtogami at redhat.com From andreas.bierfert at lowlatency.de Thu Jul 7 10:29:12 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 07 Jul 2005 12:29:12 +0200 Subject: Request for review: koffice In-Reply-To: <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> Message-ID: <42CD03F8.5040707@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jochen Schmitt wrote: >>>http://fedora.lowlatency.de/review/ [...] > I think you should delete all files on /usr/share/applnk/Office. Fix in current version... can be found at the same location - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCzQP4QEQyPsWM8csRAgKkAKC3pqcBbJGqdBNtXBYax1VgQg5HyQCdEKqw N9HBGr6yOhxMXr6oeHvsF7k= =mhJz -----END PGP SIGNATURE----- From bugs.michael at gmx.net Thu Jul 7 10:38:05 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Jul 2005 12:38:05 +0200 Subject: Take 2: greek font packages In-Reply-To: <42CCFF27.5050700@redhat.com> References: <20050705113621.GB5157@gallagher.di.uoa.gr> <20050706195205.52a67cd7.bugs.michael@gmx.net> <42CCFF27.5050700@redhat.com> Message-ID: <20050707123805.01a02eb0.bugs.michael@gmx.net> On Thu, 07 Jul 2005 00:08:39 -1000, Warren Togami wrote: > Michael Schwendt wrote: > > On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > > > > > >>The updated spec files, srpms and rpms for mgopen-fonts and > >>tetex-font-kerkis are in > >>http://gallagher.di.uoa.gr/any/rpms/ > > > > > > mgopen-fonts: Approved. > > > > Please follow the documented procedure which dictates that a message > should be posted with subject "APPROVED: packagename" so that it can be > easily found in searches. Relax. Such a message was sent at the same time to fedora-extras-commits list. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 1.34 0.84 0.35 From sarantis at cnl.di.uoa.gr Thu Jul 7 10:48:32 2005 From: sarantis at cnl.di.uoa.gr (Sarantis Paskalis) Date: Thu, 7 Jul 2005 13:48:32 +0300 Subject: Take 2: greek font packages In-Reply-To: <20050706195205.52a67cd7.bugs.michael@gmx.net> References: <20050705113621.GB5157@gallagher.di.uoa.gr> <20050706195205.52a67cd7.bugs.michael@gmx.net> Message-ID: <20050707104832.GA18776@gallagher.di.uoa.gr> On Wed, Jul 06, 2005 at 07:52:05PM +0200, Michael Schwendt wrote: > On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > > > The updated spec files, srpms and rpms for mgopen-fonts and > > tetex-font-kerkis are in > > http://gallagher.di.uoa.gr/any/rpms/ > > mgopen-fonts: Approved. OK, I incorporated the suggested changes and imported the package in CVS. The package builds here fine from a CVS checkout. If I undestood correctly, a second review is now necessary to request a build. So, please could someone take a look? Thanks, -- Sarantis From mpeters at mac.com Thu Jul 7 10:59:04 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 07 Jul 2005 03:59:04 -0700 Subject: problem with rpmlib In-Reply-To: <20050704182313.2BF8123D05@ws5-3.us4.outblaze.com> References: <20050704182313.2BF8123D05@ws5-3.us4.outblaze.com> Message-ID: <1120733945.2744.52.camel@locolhost.localdomain> On Mon, 2005-07-04 at 10:23 -0800, luya at jpopmail.com wrote: > "This has *nothing* to do with rpmlib. It's strictly a spec file problem. > Nor does it have anything to do with Fedora Extras, as that's a RPMForge > package." > > You may be fight. I used the old spec files from Colin Charles > (replacing RPMForce specs) > It provides the same error that puzzle me. Looking at the spec file - the changelog entry that Colic Charles has is for a slightly older version than what the spec file packages - so I'm guessing that the makefile changes since Colin worked on it, and became less rpm friendly. I did not try to build it (or the older version), just speculating what happened and why the spec file is now broken. It's unfortunate, but sometimes developers write their makefiles to be installed by root with make install and don't do the extra work needed to make it rpm friendly (such as offering a switch to NOT do that stuff in a buildroot) From andreas at bawue.net Thu Jul 7 11:14:42 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 7 Jul 2005 13:14:42 +0200 (CEST) Subject: Request for review: icmpdn In-Reply-To: <42CCD828.4090609@linux-kernel.at> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> Message-ID: On Thu, 7 Jul 2005, Oliver Falk wrote: > > %description > > Since the Linux kernel does not support the ICMP host name facilities as > > described in RFC 1788, I wrote a simple implementation in user-space. > > It comprises three parts: > > > > * icmpdnd - The ICMP Domain Name daemon, which listens to ICMP > > domain name requests and replies to them. > > > > * idnlookup - A user utility to query a host for its host name over > > ICMP. Like ping and all other utilities that use ICMP, it needs to > > be installed SUID root. > > > > * libnss_icmp.so.2 - A glibc NSS module, which uses idnlookup to May I suggest trimming the %description field a bit? Maybe something like: %description icmpdn is a RFC1788 ICMP Domain Name Messages implementation for linux. It contains the icmp domain name daemon, icmpdnd, which listens to ICMP domain name requests and answers them. bye, andreas From oliver at linux-kernel.at Thu Jul 7 11:25:44 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 07 Jul 2005 13:25:44 +0200 Subject: Request for review: icmpdn In-Reply-To: References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> Message-ID: <42CD1138.1050806@linux-kernel.at> On 07/07/2005 01:14 PM, Andreas Thienemann wrote: > On Thu, 7 Jul 2005, Oliver Falk wrote: > > >>>%description >>>Since the Linux kernel does not support the ICMP host name facilities as >>>described in RFC 1788, I wrote a simple implementation in user-space. >>>It comprises three parts: >>> >>> * icmpdnd - The ICMP Domain Name daemon, which listens to ICMP >>> domain name requests and replies to them. >>> >>> * idnlookup - A user utility to query a host for its host name over >>> ICMP. Like ping and all other utilities that use ICMP, it needs to >>> be installed SUID root. >>> >>> * libnss_icmp.so.2 - A glibc NSS module, which uses idnlookup to > > May I suggest trimming the %description field a bit? > > Maybe something like: > > %description > icmpdn is a RFC1788 ICMP Domain Name Messages implementation for linux. > It contains the icmp domain name daemon, icmpdnd, which listens to ICMP > domain name requests and answers them. Should be OK for me. But let Ignacio decide, if he prefers to do it or not; As this doesn't hurt. Best, Oliver From fredrik at dolda2000.com Thu Jul 7 11:40:07 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Thu, 07 Jul 2005 13:40:07 +0200 Subject: Request for review: icmpdn In-Reply-To: <42CCD828.4090609@linux-kernel.at> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> Message-ID: <1120736408.14996.48.camel@pc7.dolda2000.com> On Thu, 2005-07-07 at 09:22 +0200, Oliver Falk wrote: > On 07/06/2005 10:44 PM, Fredrik Tolf wrote: > > [...] > > Spec and SRPM: > > > > > > Bad: > * license of libs is LGPL, but LGPL license is missing. Download a copy > and included it in %doc. Oops. :-) I added it now, as COPYING.LIB. I wasn't sure whether to put it as a separate file or concatenate both the GPL or LGPL into the COPYING file and add a notice on top, but this was the way the glibc had chosen to do, so I figured it should be OK. > > Also, I'd appreciate if someone would CVS-sponsor it, since I have no > > such account. Does anyone have a link (to the wiki?) with the proper > > procedures for maintaining a package in FE? > > Do you have requested an account allready? If not, please do so: Yeah, I have requested one, but no response so far. I guess it takes a few days, right? > Someone will then cvs-sponsor you... Not me, as I havn't the right to do > so. However, in the meanwhile I can cvs-import the package for you, > request CVSSync (http://fedoraproject.org/wiki/Extras/CVSSyncNeeded) for > FC3, FC4 (any other?) and also request a bugzilla entry > (http://fedoraproject.org/wiki/Extras/BugzillaAdmin) - if you want me to > do so. If there's no other way, then yes please. > If so, please create a bugzilla account - if you don't have one > yet and let me know the mailaddress you used for register. I've had one for a while, using the same e-mail address that I'm using to send this message. Thanks for your help! Fredrik Tolf From fredrik at dolda2000.com Thu Jul 7 11:42:17 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Thu, 07 Jul 2005 13:42:17 +0200 Subject: Request for review: icmpdn In-Reply-To: References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> Message-ID: <1120736537.14996.51.camel@pc7.dolda2000.com> On Thu, 2005-07-07 at 13:14 +0200, Andreas Thienemann wrote: > On Thu, 7 Jul 2005, Oliver Falk wrote: > > > > %description > > > Since the Linux kernel does not support the ICMP host name facilities as > > > described in RFC 1788, I wrote a simple implementation in user-space. > > > It comprises three parts: > > > > > > * icmpdnd - The ICMP Domain Name daemon, which listens to ICMP > > > domain name requests and replies to them. > > > > > > * idnlookup - A user utility to query a host for its host name over > > > ICMP. Like ping and all other utilities that use ICMP, it needs to > > > be installed SUID root. > > > > > > * libnss_icmp.so.2 - A glibc NSS module, which uses idnlookup to > May I suggest trimming the %description field a bit? Now that you mention it, I do agree that it should be trimmed. That description was copied directly from the project homepage, and thus is a bit verbose. I don't really agree with your sample formulation, though, but I'll think about one and hopefully repost. Thanks! Fredrik Tolf From oliver at linux-kernel.at Thu Jul 7 11:44:54 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 07 Jul 2005 13:44:54 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120736408.14996.48.camel@pc7.dolda2000.com> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> <1120736408.14996.48.camel@pc7.dolda2000.com> Message-ID: <42CD15B6.1010304@linux-kernel.at> On 07/07/2005 01:40 PM, Fredrik Tolf wrote: > On Thu, 2005-07-07 at 09:22 +0200, Oliver Falk wrote: > >>On 07/06/2005 10:44 PM, Fredrik Tolf wrote: >> >>>[...] >>>Spec and SRPM: >>> >>> >> >>Bad: >>* license of libs is LGPL, but LGPL license is missing. Download a copy >>and included it in %doc. > > > Oops. :-) > I added it now, as COPYING.LIB. ^^^ LGPL I guess!? > I wasn't sure whether to put it as a > separate file or concatenate both the GPL or LGPL into the COPYING file > and add a notice on top, but this was the way the glibc had chosen to > do, so I figured it should be OK. No, seperate files is the way to do it. >> > Also, I'd appreciate if someone would CVS-sponsor it, since I have no >> > such account. Does anyone have a link (to the wiki?) with the proper >> > procedures for maintaining a package in FE? >> >>Do you have requested an account allready? If not, please do so. > > Yeah, I have requested one, but no response so far. I guess it takes a > few days, right? Yes, it takes a few days, 'til someone takes notice... But you can send out a mail to the list and ask if someone is willing to do it... >>Someone will then cvs-sponsor you... Not me, as I havn't the right to do >>so. However, in the meanwhile I can cvs-import the package for you, >>request CVSSync (http://fedoraproject.org/wiki/Extras/CVSSyncNeeded) for >>FC3, FC4 (any other?) and also request a bugzilla entry >>(http://fedoraproject.org/wiki/Extras/BugzillaAdmin) - if you want me to >>do so. > > > If there's no other way, then yes please. Let's see. Maybe someone had an eye on this conversation and takes notice, that you don't have a cvs sponsor yet. :-) >>If so, please create a bugzilla account - if you don't have one >>yet and let me know the mailaddress you used for register. > > I've had one for a while, using the same e-mail address that I'm using > to send this message. OK. Send me the link to the package and I'll do the work. :-) > Thanks for your help! You are welcome! Best, Oliver From oliver at linux-kernel.at Thu Jul 7 11:45:39 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 07 Jul 2005 13:45:39 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120736537.14996.51.camel@pc7.dolda2000.com> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> <1120736537.14996.51.camel@pc7.dolda2000.com> Message-ID: <42CD15E3.5010300@linux-kernel.at> On 07/07/2005 01:42 PM, Fredrik Tolf wrote: > On Thu, 2005-07-07 at 13:14 +0200, Andreas Thienemann wrote: > >>On Thu, 7 Jul 2005, Oliver Falk wrote: >> >> >>>>%description >>>>Since the Linux kernel does not support the ICMP host name facilities as >>>>described in RFC 1788, I wrote a simple implementation in user-space. >>>>It comprises three parts: >>>> >>>> * icmpdnd - The ICMP Domain Name daemon, which listens to ICMP >>>> domain name requests and replies to them. >>>> >>>> * idnlookup - A user utility to query a host for its host name over >>>> ICMP. Like ping and all other utilities that use ICMP, it needs to >>>> be installed SUID root. >>>> >>>> * libnss_icmp.so.2 - A glibc NSS module, which uses idnlookup to >> >>May I suggest trimming the %description field a bit? > > > Now that you mention it, I do agree that it should be trimmed. That > description was copied directly from the project homepage, and thus is a > bit verbose. I don't really agree with your sample formulation, though, > but I'll think about one and hopefully repost. OK, then do this and send us the link to the new package. :-) Best, Oliver From bugs.michael at gmx.net Thu Jul 7 13:06:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Jul 2005 15:06:37 +0200 Subject: Take 2: greek font packages In-Reply-To: <20050707104832.GA18776@gallagher.di.uoa.gr> References: <20050705113621.GB5157@gallagher.di.uoa.gr> <20050706195205.52a67cd7.bugs.michael@gmx.net> <20050707104832.GA18776@gallagher.di.uoa.gr> Message-ID: <20050707150637.792c7568.bugs.michael@gmx.net> On Thu, 7 Jul 2005 13:48:32 +0300, Sarantis Paskalis wrote: > On Wed, Jul 06, 2005 at 07:52:05PM +0200, Michael Schwendt wrote: > > On Tue, 5 Jul 2005 14:36:21 +0300, Sarantis Paskalis wrote: > > > > > The updated spec files, srpms and rpms for mgopen-fonts and > > > tetex-font-kerkis are in > > > http://gallagher.di.uoa.gr/any/rpms/ > > > > mgopen-fonts: Approved. > > > > OK, I incorporated the suggested changes and imported the package in CVS. > The package builds here fine from a CVS checkout. > > If I undestood correctly, a second review is now necessary to request a > build. So, please could someone take a look? Optional, not necessary. The NewPackageProcess page attempts at explaining it like this: "[...] there is no guarantee that other contributors comment on your package, so if your primary reviewer approves your package, that is enough." -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1413_FC5 loadavg: 1.21 1.35 1.31 From nphilipp at redhat.com Thu Jul 7 13:17:31 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 07 Jul 2005 15:17:31 +0200 Subject: Request for Review: libevent In-Reply-To: <20050705165953.2084f852@nausicaa.camperquake.de> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> <42C5F4C0.2000700@di.uminho.pt> <20050704174535.269e5206@nausicaa.camperquake.de> <20050705165953.2084f852@nausicaa.camperquake.de> Message-ID: <1120742252.31740.34.camel@gibraltar.stuttgart.redhat.com> On Tue, 2005-07-05 at 16:59 +0200, Ralf Ertzinger wrote: > Hi. > > Ralf Ertzinger wrote: > > > Thanks, package is in CVS now. > > May I consider the package to be approved? Yes. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From kaboom at oobleck.net Thu Jul 7 13:35:19 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 7 Jul 2005 09:35:19 -0400 (EDT) Subject: request for review: dirvish and required perl modules In-Reply-To: References: Message-ID: On Mon, 27 Jun 2005, Chris Ricker wrote: > dirvish is a simple ssh+rsync-based file-oriented disk-to-disk network > backup application. It seems to be fairly popular in that space, and works > pretty well in my experience. If you've never tried it and are interested, > is a good > intro.... perl-Time-modules is now in - thanks! I'm still looking for reviews of perl-Period and then of dirvish thanks, chris From oliver at linux-kernel.at Thu Jul 7 13:39:15 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 07 Jul 2005 15:39:15 +0200 Subject: Request for Review: libstatgrab In-Reply-To: <42CBFC61.5030800@linux-kernel.at> References: <42CB85C0.4000008@linux-kernel.at> <1120661681.30349.130.camel@localhost.localdomain> <42CBFC61.5030800@linux-kernel.at> Message-ID: <42CD3083.1070006@linux-kernel.at> On 07/06/2005 05:44 PM, Oliver Falk wrote: > Hi Spot! [ ... ] > Just recreated the srpm and uploaded the spec: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libstatgrab > > > I just changed a few identation things, nothing relevant. > > You may have a look at it again and approve it now. Spot, no response yet!? Best, Oliver From sarantis at cnl.di.uoa.gr Thu Jul 7 13:51:31 2005 From: sarantis at cnl.di.uoa.gr (Sarantis Paskalis) Date: Thu, 7 Jul 2005 16:51:31 +0300 Subject: Take 2: greek font packages In-Reply-To: <20050707150637.792c7568.bugs.michael@gmx.net> References: <20050705113621.GB5157@gallagher.di.uoa.gr> <20050706195205.52a67cd7.bugs.michael@gmx.net> <20050707104832.GA18776@gallagher.di.uoa.gr> <20050707150637.792c7568.bugs.michael@gmx.net> Message-ID: <20050707135131.GA20649@gallagher.di.uoa.gr> On Thu, Jul 07, 2005 at 03:06:37PM +0200, Michael Schwendt wrote: > > OK, I incorporated the suggested changes and imported the package in CVS. > > The package builds here fine from a CVS checkout. > > > > If I undestood correctly, a second review is now necessary to request a > > build. So, please could someone take a look? > > Optional, not necessary. The NewPackageProcess page attempts at > explaining it like this: "[...] there is no guarantee that other > contributors comment on your package, so if your primary reviewer approves > your package, that is enough." Many thanks for the explanations. I will request the necessary builds once the branches for FC-3 and FC-4 are created. -- Sarantis From Christian.Iseli at licr.org Thu Jul 7 13:57:32 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 07 Jul 2005 15:57:32 +0200 Subject: Review still needed: barcode In-Reply-To: Your message of "Wed, 06 Jul 2005 19:54:08 +0200." Message-ID: <200507071357.j67DvW5Q019133@ludwig-alpha.unil.ch> Hi Andreas, andreas at bawue.net said: > Specfile: http://home.bawue.de/~ixs/barcode/barcode.spec > SRPM: http://home.bawue.de/~ixs/barcode/barcode-0.98-4.src.rpm Good: - rpmlint is silent - name ok - spec name ok - packaging guidelines met - license ok - license matches actual license in package - license file in %doc - spec file in American English - spec file legible - source matches upstream md5 - BuildRequires ok - files stuff: ok - clean section ok - macro useage ok - package contains code - %doc is only doc - header files in -devel - no .la files Bad: - can't install -devel package because of bad %epoch dependency: error: Failed dependencies: barcode = %{epoch}:0.98-4 is needed by barcode-devel-0.98-4.i386 Can be fixed by applying accompanying patch. - Summary line contains name (see patch) - make line not standard (see patch) - install-info is useless: install-info: warning: no info dir entry in `/usr/share/info/barcode.info.gz' install-info: warning: no entries found for `/usr/share/info/barcode.info.gz'; nothing deleted -------------- next part -------------- A non-text attachment was scrubbed... Name: barcode.spec.patch Type: application/x-patch Size: 820 bytes Desc: barcode.spec.patch URL: From lmacken at redhat.com Thu Jul 7 14:29:25 2005 From: lmacken at redhat.com (Luke Macken) Date: Thu, 7 Jul 2005 10:29:25 -0400 Subject: Request for Review: naim In-Reply-To: <20050707025947.GA12388@tomservo.boston.redhat.com> References: <20050705152955.GA13111@tomservo.boston.redhat.com> <20050707025947.GA12388@tomservo.boston.redhat.com> Message-ID: <20050707142925.GA13658@tomservo.boston.redhat.com> On Wed, Jul 06, 2005 at 10:59:47PM -0400, Luke Macken wrote: | On Tue, Jul 05, 2005 at 11:29:55AM -0400, Luke Macken wrote: | | naim is a console client for AOL Instant Messenger (AIM), AOL I Seek You | | (ICQ), Internet Relay Chat (IRC), and The lily CMC. | | | | http://people.redhat.com/lmacken/naim.spec | | http://people.redhat.com/lmacken/naim-0.11.7.3.1-1.src.rpm | | In order to please rpmlint, I made a devel subpackage for the naim and | firetalk libraries that are installed as well. Now rpmlint only spits | out a warning because there is no documentation for the devel package. Scratch that, naim-devel will probably never get used. I regressed the spec, and made rpmlint happy. luke From andreas at bawue.net Thu Jul 7 14:48:12 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 7 Jul 2005 16:48:12 +0200 (CEST) Subject: Review still needed: barcode In-Reply-To: <200507071357.j67DvW5Q019133@ludwig-alpha.unil.ch> References: <200507071357.j67DvW5Q019133@ludwig-alpha.unil.ch> Message-ID: Hello Christian, On Thu, 7 Jul 2005 Christian.Iseli at licr.org wrote: > > Specfile: http://home.bawue.de/~ixs/barcode/barcode.spec > > SRPM: http://home.bawue.de/~ixs/barcode/barcode-0.98-5.src.rpm > Bad: > - can't install -devel package because of bad %epoch dependency: fixed > Can be fixed by applying accompanying patch. > - Summary line contains name (see patch) > - make line not standard (see patch) fixed. > - install-info is useless: > install-info: warning: no info dir entry in `/usr/share/info/barcode.info.gz' > install-info: warning: no entries found for `/usr/share/info/barcode.info.gz'; nothing deleted fixed. The texinfo source needed a small patch and a rebuild. If you could take a look and approve if it's okay, I'd be grateful. bye, andreas From rc040203 at freenet.de Thu Jul 7 14:51:14 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 07 Jul 2005 16:51:14 +0200 Subject: request for review: dirvish and required perl modules In-Reply-To: References: Message-ID: <1120747874.30532.266.camel@mccallum.corsepiu.local> On Thu, 2005-07-07 at 09:35 -0400, Chris Ricker wrote: > On Mon, 27 Jun 2005, Chris Ricker wrote: > perl-Time-modules is now in - thanks! > > I'm still looking for reviews of perl-Period and then of dirvish > > I am going to approve this one. Ralf From Christian.Iseli at licr.org Thu Jul 7 15:01:52 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 07 Jul 2005 17:01:52 +0200 Subject: Review still needed: barcode In-Reply-To: Your message of "Thu, 07 Jul 2005 16:48:12 +0200." Message-ID: <200507071501.j67F1qDe019725@ludwig-alpha.unil.ch> andreas at bawue.net said: > The texinfo source needed a small patch and a rebuild. > If you could take a look and approve if it's okay, I'd be grateful. Yup, looks ok now. Approved. Cheers, Christian From katzj at redhat.com Thu Jul 7 15:44:22 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Jul 2005 11:44:22 -0400 Subject: Request for Review: naim In-Reply-To: <20050707142925.GA13658@tomservo.boston.redhat.com> References: <20050705152955.GA13111@tomservo.boston.redhat.com> <20050707025947.GA12388@tomservo.boston.redhat.com> <20050707142925.GA13658@tomservo.boston.redhat.com> Message-ID: <1120751062.27326.21.camel@bree.local.net> On Thu, 2005-07-07 at 10:29 -0400, Luke Macken wrote: > Scratch that, naim-devel will probably never get used. I regressed the > spec, and made rpmlint happy. With the change to the buildrequires we discussed on IRC, this looks good. Builds cleanly in mock, rpmlint looks fine. Only odd thing that sticks out is why the requires on screen? It looks like it gets used for the detach stuff and I can see it being useful, but not necessarily required. I can be swayed either way, though since it does provide useful functionality. Approved Jeremy From ivazquez at ivazquez.net Thu Jul 7 17:33:19 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Jul 2005 13:33:19 -0400 Subject: Request for Review: binutils-mipsel In-Reply-To: <1120480073.15363.7.camel@ignacio.ignacio.lan> References: <1120480073.15363.7.camel@ignacio.ignacio.lan> Message-ID: <1120757600.9522.3.camel@ignacio.ignacio.lan> I'm having trouble in the later parts of the toolchain, so I'm going to withdraw this package until I have it all figured out. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Jochen at herr-schmitt.de Thu Jul 7 17:34:22 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 07 Jul 2005 19:34:22 +0200 Subject: Request for review: koffice In-Reply-To: <42CD03F8.5040707@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> Message-ID: <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 07 Jul 2005 12:29:12 +0200, you wrote: >Fix in current version... can be found at the same location I could built and installed the package without problems. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQs1ns09gByurcX4MEQIK4ACeP3APzxDFTbAVkDBbjnC/NR0JWGAAn2gQ edZWxmJIBdYNFrMcWQ3TmnWC =MN20 -----END PGP SIGNATURE----- From fedora at camperquake.de Thu Jul 7 17:37:13 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 7 Jul 2005 19:37:13 +0200 Subject: Request for Review: libevent In-Reply-To: <1120742252.31740.34.camel@gibraltar.stuttgart.redhat.com> References: <20050617154437.027bab5c@nausicaa.camperquake.de> <1119021451.17422.26.camel@gibraltar.stuttgart.redhat.com> <20050617172333.19754b5e@nausicaa.camperquake.de> <42C5F4C0.2000700@di.uminho.pt> <20050704174535.269e5206@nausicaa.camperquake.de> <20050705165953.2084f852@nausicaa.camperquake.de> <1120742252.31740.34.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20050707193713.000e6733@nausicaa.camperquake.de> Hi. Nils Philippsen wrote: > > May I consider the package to be approved? > > Yes. Thanks. -- Let he who have understanding reckon the number of the Beast And that number shall be anything <=9600 bps From kapointer at charter.net Thu Jul 7 17:47:48 2005 From: kapointer at charter.net (Kyle Pointer) Date: Thu, 07 Jul 2005 12:47:48 -0500 Subject: New Package: gDesklets0.35.1 Message-ID: <1120758468.17903.9.camel@fluffbox.fluffnet> Hello. I made RPMs today for gDesklets. ( no widgets included [ it does point to the right resource though ]) [yes SRPMS and SPEC files are available as well] Anyways those are at: ftp://fluffnet.serveftp.com/rpms/gDesklets/ And I still have my nessus rpms at: ftp://fluffnet.serveftp.com/rpms/nessus/ All of which I have tested, and all of which appear to work fine. I would like to request to have these approved by someone. Or at least sent back with some constructive criticism. ( please note that the RPMs are only in i386 binary form ) -- Kyle Pointer From tcallawa at redhat.com Thu Jul 7 18:14:31 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 07 Jul 2005 13:14:31 -0500 Subject: Request for Review: libstatgrab In-Reply-To: <42CD3083.1070006@linux-kernel.at> References: <42CB85C0.4000008@linux-kernel.at> <1120661681.30349.130.camel@localhost.localdomain> <42CBFC61.5030800@linux-kernel.at> <42CD3083.1070006@linux-kernel.at> Message-ID: <1120760071.9303.22.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:39 +0200, Oliver Falk wrote: > On 07/06/2005 05:44 PM, Oliver Falk wrote: > > Hi Spot! > [ ... ] > > Just recreated the srpm and uploaded the spec: > > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libstatgrab > > > > > > I just changed a few identation things, nothing relevant. > > > > You may have a look at it again and approve it now. Looks good. In %files examples, add: %doc examples/*.c (The source code for the examples is useful documentation) But since thats a minor change (and I forgot to do it), the package is APPROVED. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at phy.duke.edu Thu Jul 7 18:39:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Jul 2005 14:39:58 -0400 Subject: extras buildsystem downtime Message-ID: <1120761599.5121.5.camel@cutter> Hi, This weekend starting on friday night (10pm GMT-5) the fedora extras buildsystems will go down so we can migrate over to the newer buildsystem code. We will be testing the code throughout the weekend and will not be accepting build submissions in this time. You can use cvs as normal to check in changes but you won't be able to submit your jobs to be built this weekend. Thanks, -sv From andreas at bawue.net Thu Jul 7 18:47:43 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 7 Jul 2005 20:47:43 +0200 (CEST) Subject: New Package: gDesklets0.35.1 In-Reply-To: <1120758468.17903.9.camel@fluffbox.fluffnet> References: <1120758468.17903.9.camel@fluffbox.fluffnet> Message-ID: On Thu, 7 Jul 2005, Kyle Pointer wrote: > Hello. I made RPMs today for gDesklets. > ( no widgets included [ it does point to the right resource though ]) > [yes SRPMS and SPEC files are available as well] > Anyways those are at: > ftp://fluffnet.serveftp.com/rpms/gDesklets/ Okay, this needs some work. First of all: rpmlint shows the most obvious problems: W: gdesklets summary-ended-with-dot The gDesklets widget manager. Please remove the dot at the end of the line. W: gdesklets spelling-error-in-description usefull useful Typo. E: gdesklets description-line-too-long gDeskets are little scripts ( with pretty pictures ) that will run on your desktop. Usefull as eye candy, to keep track of system resources, etc. Please add linebreaks between at 78chars or shorter. And a better description would be appreciated W: gdesklets no-url-tag Please add a URL with the project homepage E: gdesklets invalid-spec-name gDesklets-0.35.1.spec The spec should be named gdesklets.spec Then on to the spec file: %setup -q -c Can be substituted by %setup -q -n gDesklets-%{version} This will save you from having to chdir to the directory in each stage. The %clean stage doesn't actually clean the buildroot. Fix that please. Remove the %post message. RPM is for unattended installs, nobody will read it. Either put a message into the description that the actual widgets are not installed or put a README.redhat or README.fedora into the docdir. %files do not contain any docs nor the COPYING file. Fix that. you are using full paths in the %files section. Please use the shorthand macros such as %{_datadir} and %{_bindir} etc. %changelog does not contain the version release for which the changelog entry applies. Please fix these errors and submit a new spec, which I will review in depth. bye, andreas From gajownik at fedora.pl Thu Jul 7 19:09:12 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 07 Jul 2005 21:09:12 +0200 Subject: nessus packages [was:New Package: gDesklets0.35.1] In-Reply-To: <1120758468.17903.9.camel@fluffbox.fluffnet> References: <1120758468.17903.9.camel@fluffbox.fluffnet> Message-ID: <42CD7DD8.3020802@fedora.pl> Dnia 07/07/2005 07:47 PM, U?ytkownik Kyle Pointer napisa?: > Hello. Hi! > And I still have my nessus rpms at: > ftp://fluffnet.serveftp.com/rpms/nessus/ You still haven't resolved previously mentioned problems: http://www.redhat.com/archives/fedora-extras-list/2005-July/msg00031.html http://www.redhat.com/archives/fedora-extras-list/2005-July/msg00163.html I have almost done nessus-core.spec, so I'll add: - plugins cannot be placed in /usr/lib/nessus directory: http://bugs.nessus.org/show_bug.cgi?id=928 They should be moved to /var/lib/nessus dir (I think so) - all certificates should be moved to /etc/pki dir - it would be nice to move logs to /var/log/nessus instead of /var/nessus/logs - move nessusd.pid file to /var/run - missing nessus.desktop file - missing /etc/rc.d/init.d/nessusd file - missing /etc/logrotate.d/nessusd file - you should compile nessus-core twice to get text and GTK+ nessus client - link nessus client against system gd library. There is one problem with that: if you do so, nessus text client will require X.org X11 ;-) I still dont know how to resolve this problem :( I've made some packages just for fun, so you can take a look at them: http://80.55.221.90/~gajownik/linux/RPMS/nessus/ I haven't tested them thoroughly, because I haven't finished nessus-plugins-GPL package :/ Two things does not work right now: - nessusd.init file does not detect error exit status from nessusd; run: service nessusd start before you genereate certificates with nessus-mkcert and you'll see - %ghost section does not work in nessus-core package :/ Config files should be renamed to *.rpmsave after rpm -e nessusd, but they aren't. Hope that helps. -- ^_* From toshio at tiki-lounge.com Thu Jul 7 19:31:13 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 07 Jul 2005 15:31:13 -0400 Subject: New Package: gDesklets0.35.1 In-Reply-To: <1120758468.17903.9.camel@fluffbox.fluffnet> References: <1120758468.17903.9.camel@fluffbox.fluffnet> Message-ID: <1120764673.23113.16.camel@localhost> On Thu, 2005-07-07 at 12:47 -0500, Kyle Pointer wrote: > Hello. I made RPMs today for gDesklets. > ( no widgets included [ it does point to the right resource though ]) > [yes SRPMS and SPEC files are available as well] > Anyways those are at: > ftp://fluffnet.serveftp.com/rpms/gDesklets/ > And I still have my nessus rpms at: > ftp://fluffnet.serveftp.com/rpms/nessus/ > > All of which I have tested, and all of which appear to work fine. > I would like to request to have these approved by someone. > Or at least sent back with some constructive criticism. > ( please note that the RPMs are only in i386 binary form ) > There was some work done on a gDesklets package for fedora.us. I don't know how it compares to yours as of yet: http://bugzilla.fedora.us/show_bug.cgi?oid=2025 -Toshio -------------- 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 fredrik at dolda2000.com Thu Jul 7 19:41:23 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Thu, 07 Jul 2005 21:41:23 +0200 Subject: Request for review: icmpdn In-Reply-To: <42CD15B6.1010304@linux-kernel.at> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> <1120736408.14996.48.camel@pc7.dolda2000.com> <42CD15B6.1010304@linux-kernel.at> Message-ID: <1120765283.14996.57.camel@pc7.dolda2000.com> On Thu, 2005-07-07 at 13:44 +0200, Oliver Falk wrote: > On 07/07/2005 01:40 PM, Fredrik Tolf wrote: > > On Thu, 2005-07-07 at 09:22 +0200, Oliver Falk wrote: > > > >>On 07/06/2005 10:44 PM, Fredrik Tolf wrote: > >> > >>>[...] > >>>Spec and SRPM: > >>> > >>> > >> > >>Bad: > >>* license of libs is LGPL, but LGPL license is missing. Download a copy > >>and included it in %doc. > > Oops. :-) > > I added it now, as COPYING.LIB. > ^^^ LGPL I guess!? > > I wasn't sure whether to put it as a > > separate file or concatenate both the GPL or LGPL into the COPYING file > > and add a notice on top, but this was the way the glibc had chosen to > > do, so I figured it should be OK. > No, seperate files is the way to do it. I think you may have misunderstood me. I did use seperate files, as did glibc. glibc had named the file which contains the LGPL "COPYING.LIB", so I did the same, for the sake of consistency. I had planned to name the file COPYING.LGPL, but since glibc had named it COPYING.LIB, I thought it better to keep that convention. Do you not agree? > >>Someone will then cvs-sponsor you... Not me, as I havn't the right to do > >>so. However, in the meanwhile I can cvs-import the package for you, > >>request CVSSync (http://fedoraproject.org/wiki/Extras/CVSSyncNeeded) for > >>FC3, FC4 (any other?) and also request a bugzilla entry > >>(http://fedoraproject.org/wiki/Extras/BugzillaAdmin) - if you want me to > >>do so. > > > > > > If there's no other way, then yes please. > > Let's see. Maybe someone had an eye on this conversation and takes > notice, that you don't have a cvs sponsor yet. :-) > > >>If so, please create a bugzilla account - if you don't have one > >>yet and let me know the mailaddress you used for register. > > > > I've had one for a while, using the same e-mail address that I'm using > > to send this message. > > OK. Send me the link to the package and I'll do the work. :-) Same links as before, but I can repeat them for the sake of completeness: I hope you find this OK. Fredrik Tolf From andreas at bawue.net Thu Jul 7 19:45:27 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 7 Jul 2005 21:45:27 +0200 (CEST) Subject: New Package: gDesklets0.35.1 In-Reply-To: <1120764673.23113.16.camel@localhost> References: <1120758468.17903.9.camel@fluffbox.fluffnet> <1120764673.23113.16.camel@localhost> Message-ID: On Thu, 7 Jul 2005, Toshio Kuratomi wrote: > There was some work done on a gDesklets package for fedora.us. I don't > know how it compares to yours as of yet: > http://bugzilla.fedora.us/show_bug.cgi?oid=2025 I had a short look at the Spec from Phil and it looked much more advanced than the one from Kyle, even more so with the spec patches from bugzilla. Maybe if one would add a find_lang to it for the locale files and fix the remaining issues, it could be imported into extras. bye, andreas From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 7 19:49:37 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 7 Jul 2005 21:49:37 +0200 Subject: nvu In-Reply-To: <42C7D246.7070905@redhat.com> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> <42C7D246.7070905@redhat.com> Message-ID: <20050707214937.7fc3ce96@python2> Christopher Aillon wrote : > > Is anyone interested in packaging nvu? > > https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00012.html Christopher, using your firefox mozconfig and bits and pieces of the spec file (ah, the wonderful "tar everything up, then untar it all!" ;-)), I've made a quick working first package of Nvu. The only major blocker I saw was that without --disable-crypto, the build failed on FC4 i386, on a .h file which is identical to the one in the 1.0.4 firefox tree, go figure. I'm behind a 128kbps upload link, so I'll be putting the source and binary packages up only tomorrow. In the meantime there are the spec, mozconfig and desktop files there. http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/4/nvu/ I'm sure there is room for plenty of improvements (overall integration, including some plugins, making sure the mozconfig is optimal etc.), so let the suggestions begin! Once the package has been tested some more, I'll request formal reviews ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 1.34 0.77 0.84 From caillon at redhat.com Thu Jul 7 20:21:03 2005 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 07 Jul 2005 16:21:03 -0400 Subject: nvu In-Reply-To: <20050707214937.7fc3ce96@python2> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> <42C7D246.7070905@redhat.com> <20050707214937.7fc3ce96@python2> Message-ID: <42CD8EAF.8020600@redhat.com> On 07/07/2005 03:49 PM, Matthias Saou wrote: >Christopher Aillon wrote : > > > >>>Is anyone interested in packaging nvu? >>> >>> >>https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00012.html >> >> > >Christopher, using your firefox mozconfig and bits and pieces of the spec >file (ah, the wonderful "tar everything up, then untar it all!" ;-)), I've >made a quick working first package of Nvu. > >The only major blocker I saw was that without --disable-crypto, the build >failed on FC4 i386, on a .h file which is identical to the one in the >1.0.4 firefox tree, go figure. > > Interesting -- got a build log? Crypto is probably something we'd want to support here for pushing to some things such as krb5 realms, etc. (not sure if that's even an option in today's nvu, but still...) >I'm behind a 128kbps upload link, so I'll be putting the source and binary >packages up only tomorrow. In the meantime there are the spec, mozconfig >and desktop files there. > >http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/4/nvu/ > >I'm sure there is room for plenty of improvements (overall integration, >including some plugins, making sure the mozconfig is optimal etc.), so let >the suggestions begin! Once the package has been tested some more, I'll >request formal reviews ;-) > > Some quick comments: .desktop file: Name and GenericName should be nouns, not verbs. I'd suggest: Name=Nvu Web Authoring Tool GenericName=Web Authoring Tool (note that the GenericName does not include the app name, e.g. the Firefox desktop file et.al) The Comment sounds odd to me, but offhand, can't think of anything better to put there. .spec: Do we have all the pango patches we need to --enable-pango? Not sure whether those made it into nvu's branch or not, but we should add them if not. Especially so for rawhide, since the removal of xft caused text to not render properly in firefox without the latest patch in the rawhide RPM (firefox-1.0-pango-cairo.patch). You'll probably also need some of the patches requried to compile firefox on rawhide (the gcc4 patches, prdtoa patches, etc). I'll do a more formal review when you're ready. From tcallawa at redhat.com Thu Jul 7 20:33:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 07 Jul 2005 15:33:08 -0500 Subject: Request for review: perl-Maypole (and friends) Message-ID: <1120768388.9303.40.camel@localhost.localdomain> Recently, I've heard a fair amount of buzz about something called Maypole (Linux Journal did a piece about an 18 line web application). So, I decided that I would package it up. And I succeeded, but man, oh, man, does that thing have dependencies. So, I am requesting review for perl-Maypole, and the 39 other packages that it needed as dependencies. Now, before everyone freaks and runs the other direction, the vast majority of these packages are perl noarch, straight off the template. All of the specs and SRPMs can be found in here: http://auroralinux.org/people/spot/review/Maypole/ The packages are: libapreq2: Library for manipulating client request data via the Apache API perl-CGI-Simple: Simple totally OO CGI interface that is CGI.pm compliant perl-CGI-Untaint-date: Validate a date perl-CGI-Untaint: Process CGI input parameters perl-Class-Accessor-Chained: Make chained accessors perl-Class-Data-Inheritable: Inheritable, overridable class data perl-Class-DBI-AbstractSearch: Abstract Class::DBI's SQL with SQL::Abstract perl-Class-DBI-AsForm: Produce HTML form elements for database columns perl-Class-DBI-FromCGI: Update Class::DBI data using CGI::Untaint perl-Class-DBI-Loader-Relationship: Easier relationship specification in CDBI::L perl-Class-DBI-Loader: Dynamic definition of Class::DBI sub classes perl-Class-DBI-mysql: Extensions to Class::DBI for MySQL perl-Class-DBI-Pager: Pager utility for Class::DBI perl-Class-DBI-Pg: Class::DBI extension for PostgreSQL perl-Class-DBI-Plugin-RetrieveAll: More complex retrieve_all() for Class::DBI perl-Class-DBI-Plugin: Abstract base class for Class::DBI plugins perl-Class-DBI-Plugin-Type: Determine type information for columns perl-Class-DBI: Simple Database Abstraction perl-Class-DBI-SQLite: Extension to Class::DBI for sqlite perl-Class-Trigger: Mixin to add / call inheritable triggers perl-Class-Whitehole: Base class to treat unhandled method calls as errors perl-Data-Page: Help when paging through sets of results perl-DBD-SQLite2: Self Contained RDBMS in a DBI Driver (sqlite 2.x) perl-DBIx-ContextualFetch: Add contextual fetches to DBI perl-Exporter-Lite: Lightweight exporting of variables perl-ExtUtils-XSBuilder: Modules that parse C header files and create XS glue code perl-Ima-DBI: Database connection caching and organization perl-IO-CaptureOutput: Capture STDOUT/STDERR from subprocesses and XS/C modules perl-IO-stringy: I/O on in-core objects like strings and arrays perl-Lingua-EN-Inflect-Number: Force number of words to singular or plural perl-Lingua-EN-Inflect: Convert singular to plural, select "a" or "an" perl-Maypole: MVC web application framework perl-SQL-Abstract: Generate SQL from Perl data structures perl-Template-Plugin-Class: Allow calling of class methods on arbitrary classes perl-Template-Toolkit: Template processing system perl-Test-MockModule: Override subroutines in a module for unit testing perl-Tie-DBI: Tie hashes to DBI relational databases perl-UNIVERSAL-exports: Lightweight, universal exporting of variables perl-UNIVERSAL-moniker: Real world naming for classes Perl people, I'm looking at you to do reviews/approvals if possible. However, we're going to need a lot of people to help review all these packages. If you've got CVS access, you can review packages. Any and all help is appreciated. I put a fair amount of work into this effort (a lot more than I thought it would require at the start), and I'd hate to see it go to waste because it couldn't all get reviewed. Thanks in advance, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Thu Jul 7 20:50:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Jul 2005 16:50:39 -0400 Subject: Request for review: libifp Message-ID: <1120769439.9522.6.camel@ignacio.ignacio.lan> libifp: A general-purpose library-driver for iRiver's iFP portable audio players libifp is a general-purpose library-driver for iRiver's iFP (flash-based) portable audio players. The source code is pure C and is fairly portable. Also included is a console app that uses the library. http://fedora.ivazquez.net/files/extras/libifp.spec http://fedora.ivazquez.net/files/extras/libifp-1.0.0.1-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Thu Jul 7 20:59:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 07 Jul 2005 15:59:14 -0500 Subject: Request for review: libifp In-Reply-To: <1120769439.9522.6.camel@ignacio.ignacio.lan> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> Message-ID: <1120769954.9303.50.camel@localhost.localdomain> On Thu, 2005-07-07 at 16:50 -0400, Ignacio Vazquez-Abrams wrote: > libifp: A general-purpose library-driver for iRiver's iFP portable audio > players > > libifp is a general-purpose library-driver for iRiver's iFP > (flash-based) portable audio players. The source code is pure C and is > fairly portable. > > Also included is a console app that uses the library. > > http://fedora.ivazquez.net/files/extras/libifp.spec > http://fedora.ivazquez.net/files/extras/libifp-1.0.0.1-1.src.rpm Review: rpmlint checks: libifp-1.0.0.1-1.i386.rpm: E: libifp outside-libdir-files /usr/bin/ifpline libifp-devel-1.0.0.1-1.i386.rpm: W: libifp-devel no-dependency-on libifp You just need to add some spaces in the %devel area. Instead of: Requires: %{name}=%{version}-%{release} use Requires: %{name} = %{version}-%{release} The other error is rpmlint being stupid, and can be ignored. Good: - Meets Naming and PackagingGuidelines - License OK (GPL), text included, matches code - shared libraries handled properly - devel package has correct files - code not content - spec file is legible, correct - %clean is present - macro use is consistent - post/postun is correct for shared libs - la files are deleted Since the only blocker is minor, I'm approving this. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From lmacken at redhat.com Thu Jul 7 20:53:28 2005 From: lmacken at redhat.com (Luke Macken) Date: Thu, 7 Jul 2005 16:53:28 -0400 Subject: Request for Review: naim In-Reply-To: <1120751062.27326.21.camel@bree.local.net> References: <20050705152955.GA13111@tomservo.boston.redhat.com> <20050707025947.GA12388@tomservo.boston.redhat.com> <20050707142925.GA13658@tomservo.boston.redhat.com> <1120751062.27326.21.camel@bree.local.net> Message-ID: <20050707205328.GB14611@tomservo.boston.redhat.com> On Thu, Jul 07, 2005 at 11:44:22AM -0400, Jeremy Katz wrote: | Only odd thing that sticks out is why the requires on screen? It looks | like it gets used for the detach stuff and I can see it being useful, | but not necessarily required. I can be swayed either way, though since | it does provide useful functionality. I removed the screen dependency and disabled detach-mode. I looked into it a bit more and noticed that executing /detach in naim seems to improperly detach the screen session and break the users console, requiring a `reset`. Also, to resume your naim session you have to `screen -r` (as opposed to `naim`, and having it automatically resume your session), which seems pointless. If people want to use screen, they can run it by hand (as naim already requires the user to know how to resume sessions anyway). This package is now imported into cvs, and is waiting to get APPROVED. luke From andreas.bierfert at lowlatency.de Thu Jul 7 21:20:48 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 07 Jul 2005 23:20:48 +0200 Subject: Request for review: koffice In-Reply-To: <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> Message-ID: <42CD9CB0.80209@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jochen Schmitt wrote: > On Thu, 07 Jul 2005 12:29:12 +0200, you wrote: > > >>>Fix in current version... can be found at the same location > > > I could built and installed the package without problems. Thanks for your review. If you run into any other problems let me know. Anybody else willing to review? Or anybody against importing these packages to cvs and if so why? ^^ - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCzZywQEQyPsWM8csRAtGaAJ4+zVmZVRqKN4LcG5JbjRNyMCq89QCfRHd1 Yt1sa0dJwy5aeWyrraW2E2g= =7/4G -----END PGP SIGNATURE----- From kapointer at charter.net Thu Jul 7 21:24:20 2005 From: kapointer at charter.net (Kyle Pointer) Date: Thu, 07 Jul 2005 16:24:20 -0500 Subject: nessus packages [was:New Package: gDesklets0.35.1] In-Reply-To: <42CD7DD8.3020802@fedora.pl> References: <1120758468.17903.9.camel@fluffbox.fluffnet> <42CD7DD8.3020802@fedora.pl> Message-ID: <1120771460.17903.12.camel@fluffbox.fluffnet> > You still haven't resolved previously mentioned problems: > http://www.redhat.com/archives/fedora-extras-list/2005-July/msg00031.html > http://www.redhat.com/archives/fedora-extras-list/2005-July/msg00163.html Yeah, I'm sorry about that. I had missed those messages somehow. I'll keep working at this. I've not had much experience with building RPMs, and I'm sure my work reflects that. ;-) -- Kyle Pointer From perbj at stanford.edu Thu Jul 7 21:46:14 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 07 Jul 2005 14:46:14 -0700 Subject: Request for review: libifp In-Reply-To: <1120769439.9522.6.camel@ignacio.ignacio.lan> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> Message-ID: <1120772774.2903.47.camel@localhost.localdomain> On Thu, 2005-07-07 at 16:50 -0400, Ignacio Vazquez-Abrams wrote: > libifp: A general-purpose library-driver for iRiver's iFP portable audio > players Cool! This is one of the things I have been looking at but I have been way too sidetracked with writing my thesis to get anywhere with Fedora stuff yet... I have one question though: Does this actually work correctly nowadays as a regular user without any tricky chowning of the device file in /proc/bus/usb/ ? I stole the scripts that do this for digital cameras (shipped with gphoto) and adjusted for iriver players. (I may still be missing some relevant USB IDs in the usermap file but that's a pretty easy fix.) The developer told me that it seemed to work without any trickery on FC3 but I never ever got that to work. (I suspected that he had forgotten that he hacked his usb.usermap file at some point... ;) ) I haven't tried on FC4 yet. Unfortunately I don't have an iriver here to test with so I may be off base. Perhaps HAL actually deals with handing the device over to the console owner nowadays? In any case, attached is a ever-so-slightly hacked copy of the hotplug script from the gphoto package, and the "usermap" file which identifies the iriver devices. If your package doesn't work without being root you can put these in /etc/hotplug/usb and that should hand the device over to the current console owner when it is plugged in, just like a digital camera is. On another note, if this is not necessary, the gphoto package should probably be changed not to do this either, I can't see where ther difference is... I'll test at home tonight if these are necessary, using your package. Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University -------------- next part -------------- A non-text attachment was scrubbed... Name: libifp Type: application/x-shellscript Size: 1846 bytes Desc: not available URL: -------------- next part -------------- # This file is shipped with libifp (based on a similar file in # the libsane package as shipped by Red Hat). # # The entries below are used to detect an iRiver iFP portable music # player when it is plugged in and then run the libifp hotplug script to # change the ownership and permissions on the "device node" used by # libusb. # # The 0x0003 match flag means the device is matched by its vendor and # product IDs. # # Sample entry (replace 0xVVVV and 0xPPPP with vendor ID and product ID respectively) : # libiriver 0x0003 0xVVVV 0xPPPP 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 # # usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info # # # The following list already contains the known iRiver iFP devices, with the # product IDs copied from the header file for libifp. # If it doesn't work for yours, try adding an appropriate entry. # iRiver iFP-1XX libifp 0x0003 0x4102 0x1001 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver iFP-3XX libifp 0x0003 0x4102 0x1003 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver iFP-5XX libifp 0x0003 0x4102 0x1005 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver iFP-7XX libifp 0x0003 0x4102 0x1007 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver iFP-8XX libifp 0x0003 0x4102 0x1008 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver iFP-9XX libifp 0x0003 0x4102 0x1009 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver iFP-10XX libifp 0x0003 0x4102 0x1010 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 #iRiver N10 libifp 0x0003 0x4102 0x1011 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 From jspaleta at gmail.com Thu Jul 7 21:54:35 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 Jul 2005 17:54:35 -0400 Subject: Request for additional reviews of glabels. Message-ID: <604aa791050707145489c16c0@mail.gmail.com> Now that glabels is in extras cvs, anyone have any additional comments before I request builds? -jef From i.pilcher at comcast.net Thu Jul 7 21:57:47 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 07 Jul 2005 16:57:47 -0500 Subject: New package: nedit In-Reply-To: <1119281381.7701.118.camel@locolhost.localdomain> References: <1118998986.11814.31.camel@obelix.redhat.usu> <1118999966.27626.4.camel@locolhost.localdomain> <1119000090.11814.34.camel@obelix.redhat.usu> <1119001146.27626.14.camel@locolhost.localdomain> <1119270647.24267.19.camel@obelix.redhat.usu> <1119281381.7701.118.camel@locolhost.localdomain> Message-ID: Michael A. Peters wrote: > Looks good to me, builds in mock. So what happens now (and when does it happen)? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From ivazquez at ivazquez.net Thu Jul 7 22:16:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Jul 2005 18:16:39 -0400 Subject: Request for review: libifp In-Reply-To: <1120772774.2903.47.camel@localhost.localdomain> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> <1120772774.2903.47.camel@localhost.localdomain> Message-ID: <1120774599.9522.14.camel@ignacio.ignacio.lan> On Thu, 2005-07-07 at 14:46 -0700, Per Bjornsson wrote: > On Thu, 2005-07-07 at 16:50 -0400, Ignacio Vazquez-Abrams wrote: > > libifp: A general-purpose library-driver for iRiver's iFP portable audio > > players > > Cool! This is one of the things I have been looking at but I have been > way too sidetracked with writing my thesis to get anywhere with Fedora > stuff yet... > > I have one question though: Does this actually work correctly nowadays > as a regular user without any tricky chowning of the device file > in /proc/bus/usb/ ? I stole the scripts that do this for > digital cameras (shipped with gphoto) and adjusted for iriver players. > (I may still be missing some relevant USB IDs in the usermap file but > that's a pretty easy fix.) The developer told me that it seemed to work > without any trickery on FC3 but I never ever got that to work. (I > suspected that he had forgotten that he hacked his usb.usermap file at > some point... ;) ) I haven't tried on FC4 yet. Unfortunately it doesn't. But I'll take a look at the files and tweak them as necessary, thanks. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 perbj at stanford.edu Thu Jul 7 22:32:46 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 07 Jul 2005 15:32:46 -0700 Subject: Request for review: libifp In-Reply-To: <1120774599.9522.14.camel@ignacio.ignacio.lan> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> <1120772774.2903.47.camel@localhost.localdomain> <1120774599.9522.14.camel@ignacio.ignacio.lan> Message-ID: <1120775567.2903.55.camel@localhost.localdomain> On Thu, 2005-07-07 at 18:16 -0400, Ignacio Vazquez-Abrams wrote: > Unfortunately it doesn't. But I'll take a look at the files and tweak > them as necessary, thanks. Good to know. As far as I can see the library really needs some way of turning the device over to the console owner to be useful - demanding that it be run as root is just wrong. The files I attached are based on what is used for both USB cameras and scanners so they would seem to be close to the Fedora way of solving this problem at the moment. The only tweaking I believe is necessary is to make sure that the script ("libifp") is executable. (Also, if I missed any device IDs they should go in the usermap file of course.) Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From mpeters at mac.com Thu Jul 7 22:34:50 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 07 Jul 2005 15:34:50 -0700 Subject: Request for additional reviews of glabels. In-Reply-To: <604aa791050707145489c16c0@mail.gmail.com> References: <604aa791050707145489c16c0@mail.gmail.com> Message-ID: <1120775691.2744.77.camel@locolhost.localdomain> On Thu, 2005-07-07 at 17:54 -0400, Jeff Spaleta wrote: > Now that glabels is in extras cvs, anyone have any additional comments > before I request builds? Change Source to Source0 - but otherwise it looks good to me. From bugs.michael at gmx.net Thu Jul 7 23:38:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 8 Jul 2005 01:38:10 +0200 Subject: Request for review: ncview In-Reply-To: <1120673289.10305.297.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> <1120668164.10305.287.camel@ernie> <20050706191450.49c1e13e.bugs.michael@gmx.net> <1120673289.10305.297.camel@ernie> Message-ID: <20050708013810.64ad550f.bugs.michael@gmx.net> On Wed, 06 Jul 2005 14:08:09 -0400, Ed Hill wrote: > > It prints a security relevant warning, which ought to be examined > > closer: > > > > /home/misc5/tmp/rpm/BUILD/ncview-1.92e/do_print.c:91: warning: the use of `tmpna > > m' is dangerous, better use `mkstemp' > > I've written and added a patch that seems to do the right thing. I would close the open file descriptor returned by mkstemp. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1421_FC5 loadavg: 1.01 1.19 1.39 From ed at eh3.com Thu Jul 7 23:56:17 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 07 Jul 2005 19:56:17 -0400 Subject: Request for review: ncview In-Reply-To: <20050708013810.64ad550f.bugs.michael@gmx.net> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> <1120613945.10305.232.camel@ernie> <42CC0074.1070602@ieee.org> <1120668164.10305.287.camel@ernie> <20050706191450.49c1e13e.bugs.michael@gmx.net> <1120673289.10305.297.camel@ernie> <20050708013810.64ad550f.bugs.michael@gmx.net> Message-ID: <1120780577.18460.17.camel@ernie> On Fri, 2005-07-08 at 01:38 +0200, Michael Schwendt wrote: > On Wed, 06 Jul 2005 14:08:09 -0400, Ed Hill wrote: > > > > It prints a security relevant warning, which ought to be examined > > > closer: > > > > > > /home/misc5/tmp/rpm/BUILD/ncview-1.92e/do_print.c:91: warning: the use of `tmpna > > > m' is dangerous, better use `mkstemp' > > > > I've written and added a patch that seems to do the right thing. > > I would close the open file descriptor returned by mkstemp. OK, will do! Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From ed at eh3.com Fri Jul 8 01:22:44 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 07 Jul 2005 21:22:44 -0400 Subject: Request for Review: opendap In-Reply-To: <1120608908.30349.59.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1120608908.30349.59.camel@localhost.localdomain> Message-ID: <1120785765.18460.63.camel@ernie> On Tue, 2005-07-05 at 19:15 -0500, Tom 'spot' Callaway wrote: > In a stunning blast from the past, I present... opendap! > SRPM: > http://www.auroralinux.org/people/spot/review/opendap-3.4.4-4.src.rpm Hi Spot, I'll put the bad first since its very easily fixed: Bad: - please change: install -m755 include/* $RPM_BUILD_ROOT/%{_includedir}/opendap to: install -m644 include/* $RPM_BUILD_ROOT/%{_includedir}/opendap - missing: BuildRequires: libxml2-devel Not-sure: - lots of warnings about stuff like redefinitions of _REENTRANT but I suppose we can ignore them since they don't look security related Good: - all the stuff I whined about in the earlier emails appears to be fixed :-) - no (other than above perms) complaints from rpmlint - spec looks good - licenses OK - no *.la installed - all dirs are owned - on FC3 and FC4 on i386: it builds, installs, and all the binaries that I tried worked (no more seg faults) - BONUS: yes, it does work nicely with the in-progress nco package Sorry, I just don't have enough time right now to setup and play with the server parts. But that can be tested later and shouldn't block the other two packages in any case. I'll send an approved message next. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From fredrik at dolda2000.com Fri Jul 8 01:30:41 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Fri, 08 Jul 2005 03:30:41 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120765283.14996.57.camel@pc7.dolda2000.com> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> <1120736408.14996.48.camel@pc7.dolda2000.com> <42CD15B6.1010304@linux-kernel.at> <1120765283.14996.57.camel@pc7.dolda2000.com> Message-ID: <1120786241.14996.59.camel@pc7.dolda2000.com> On Thu, 2005-07-07 at 21:41 +0200, Fredrik Tolf wrote: > Same links as before, but I can repeat them for the sake of > completeness: > > I forgot to mention that this revision also includes the %description trimming previously suggested. Fredrik Tolf From ivazquez at ivazquez.net Fri Jul 8 02:54:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Jul 2005 22:54:44 -0400 Subject: Request for review: gnome-applet-rhythmbox Message-ID: <1120791285.9522.18.camel@ignacio.ignacio.lan> gnome-applet-rhythmbox: A GNOME panel applet to control Rhythmbox's playback Rhythmbox Applet is a small, simple GNOME panel applet that lets you control Rhythmbox's playback from a panel. http://fedora.ivazquez.net/files/extras/gnome-applet-rhythmbox.spec http://fedora.ivazquez.net/files/extras/gnome-applet-rhythmbox-0.1.7-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 rc040203 at freenet.de Fri Jul 8 04:27:30 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 Jul 2005 06:27:30 +0200 Subject: Request for additional reviews of glabels. In-Reply-To: <604aa791050707145489c16c0@mail.gmail.com> References: <604aa791050707145489c16c0@mail.gmail.com> Message-ID: <1120796850.30532.309.camel@mccallum.corsepiu.local> On Thu, 2005-07-07 at 17:54 -0400, Jeff Spaleta wrote: > Now that glabels is in extras cvs, anyone have any additional comments > before I request builds? Two minor issues: %doc %{_mandir}/man1/glabels.1* The %doc on this line is redundant (files under %_mandir automatically are docs). %doc %{_datadir}/gnome/help/glabels/ I would not mark "help files" %doc, because references to them are not unlikely to be hard-coded into the application. So, if a user installs the package with "--excludedocs", he could end up with a broken application (I haven't actually tried with this package). Ralf From perbj at stanford.edu Fri Jul 8 06:53:57 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 07 Jul 2005 23:53:57 -0700 Subject: Request for review: libifp In-Reply-To: <1120774599.9522.14.camel@ignacio.ignacio.lan> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> <1120772774.2903.47.camel@localhost.localdomain> <1120774599.9522.14.camel@ignacio.ignacio.lan> Message-ID: <1120805637.2789.7.camel@localhost.localdomain> On Thu, 2005-07-07 at 18:16 -0400, Ignacio Vazquez-Abrams wrote: > Unfortunately it doesn't. But I'll take a look at the files and tweak > them as necessary, thanks. Works fine for me on FC4 as checked into Extras CVS (with the hotplug scripts). Looks good to go to me! Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From oliver at linux-kernel.at Fri Jul 8 07:01:02 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 09:01:02 +0200 Subject: APPROVED: icmpdn Message-ID: <42CE24AE.7000903@linux-kernel.at> icmpdn: ICMP host name utilities icmpdn is an implementation of the RFC 1788 ICMP domain name facilities for Linux. It includes icmpdnd, a daemon which responds to ICMP domain name requests from other hosts, idnlookup, which requests the domain name of another host, and nss_icmp, which is a nameswitch module for doing reverse hostname lookups via idnlookup. Maintainer: Fredrik Tolf Reviewer: Oliver Falk From oliver at linux-kernel.at Fri Jul 8 07:01:16 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 09:01:16 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120765283.14996.57.camel@pc7.dolda2000.com> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> <1120736408.14996.48.camel@pc7.dolda2000.com> <42CD15B6.1010304@linux-kernel.at> <1120765283.14996.57.camel@pc7.dolda2000.com> Message-ID: <42CE24BC.6060603@linux-kernel.at> On 07/07/2005 09:41 PM, Fredrik Tolf wrote: > On Thu, 2005-07-07 at 13:44 +0200, Oliver Falk wrote: > >>On 07/07/2005 01:40 PM, Fredrik Tolf wrote: >> >>>On Thu, 2005-07-07 at 09:22 +0200, Oliver Falk wrote: >>> >>> >>>>On 07/06/2005 10:44 PM, Fredrik Tolf wrote: >>>> >>>> >>>>>[...] >>>>>Spec and SRPM: >>>>> >>>>> >>>> >>>>Bad: >>>>* license of libs is LGPL, but LGPL license is missing. Download a copy >>>>and included it in %doc. >>> >>>Oops. :-) >>>I added it now, as COPYING.LIB. >> >> ^^^ LGPL I guess!? >> > I wasn't sure whether to put it as a >> >>>separate file or concatenate both the GPL or LGPL into the COPYING file >>>and add a notice on top, but this was the way the glibc had chosen to >>>do, so I figured it should be OK. >> >>No, seperate files is the way to do it. > > > I think you may have misunderstood me. I did use seperate files, as did > glibc. glibc had named the file which contains the LGPL "COPYING.LIB", > so I did the same, for the sake of consistency. I had planned to name > the file COPYING.LGPL, but since glibc had named it COPYING.LIB, I > thought it better to keep that convention. Do you not agree? > > >>>>Someone will then cvs-sponsor you... Not me, as I havn't the right to do >>>>so. However, in the meanwhile I can cvs-import the package for you, >>>>request CVSSync (http://fedoraproject.org/wiki/Extras/CVSSyncNeeded) for >>>>FC3, FC4 (any other?) and also request a bugzilla entry >>>>(http://fedoraproject.org/wiki/Extras/BugzillaAdmin) - if you want me to >>>>do so. >>> >>> >>>If there's no other way, then yes please. >> >>Let's see. Maybe someone had an eye on this conversation and takes >>notice, that you don't have a cvs sponsor yet. :-) >> >> >>>>If so, please create a bugzilla account - if you don't have one >>>>yet and let me know the mailaddress you used for register. >>> >>>I've had one for a while, using the same e-mail address that I'm using >>>to send this message. >> >>OK. Send me the link to the package and I'll do the work. :-) > > > Same links as before, but I can repeat them for the sake of > completeness: > > > > I hope you find this OK. > > Fredrik Tolf Approval sent out. Best, Oliver From adrian at lisas.de Fri Jul 8 08:25:36 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 8 Jul 2005 10:25:36 +0200 Subject: Request for additional reviews of glabels. In-Reply-To: <1120796850.30532.309.camel@mccallum.corsepiu.local> References: <604aa791050707145489c16c0@mail.gmail.com> <1120796850.30532.309.camel@mccallum.corsepiu.local> Message-ID: <20050708082536.GA13317@lisas.de> On Fri, Jul 08, 2005 at 06:27:30AM +0200, Ralf Corsepius wrote: > %doc %{_datadir}/gnome/help/glabels/ > I would not mark "help files" %doc, because references to them are not > unlikely to be hard-coded into the application. So, if a user installs > the package with "--excludedocs", he could end up with a broken > application (I haven't actually tried with this package). I have tried it and it still works with "--excludedocs" Adrian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 09:55:10 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 11:55:10 +0200 Subject: Request for review: libifp In-Reply-To: <1120805637.2789.7.camel@localhost.localdomain> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> <1120772774.2903.47.camel@localhost.localdomain> <1120774599.9522.14.camel@ignacio.ignacio.lan> <1120805637.2789.7.camel@localhost.localdomain> Message-ID: <20050708115510.4956eb28@python2> Per Bjornsson wrote : > On Thu, 2005-07-07 at 18:16 -0400, Ignacio Vazquez-Abrams wrote: > > Unfortunately it doesn't. But I'll take a look at the files and tweak > > them as necessary, thanks. > > Works fine for me on FC4 as checked into Extras CVS (with the hotplug > scripts). Looks good to go to me! Neat. I'll give it a try later today too, then. Does anyone have plans to also include a GUI application that uses libifp? Last time I searched around, most of them still relied on much older libifp versions (basically running the binaries instead of using the new lib), and/or were in very early stages. Up to now, I've always used libifp only once on each iRiver device I've had, to just flash a USB Mass Storage firmware to the device, but the main drawback is that song ordering in directories is pretty much randomly set when using UMS (i.e. not alphabetical), which isn't the case with the "manager" (so, using libifp) from what I've read. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.10 0.36 0.40 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 11:18:15 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 13:18:15 +0200 Subject: Approved - perl-DBD-SQLite In-Reply-To: <1118517992.2667.88.camel@laptop.mpeters.local> References: <1118516616.2667.83.camel@laptop.mpeters.local> <1118516783.2457.9.camel@cutter> <1118517992.2667.88.camel@laptop.mpeters.local> Message-ID: <20050708131815.0acfac43@python2> Michael A. Peters wrote : > > wait, what??? > > > > it includes a duplicate copy of SQLite? > > > > That's kinda crack, isn't it? > > Yes. And the wiki about fc5 says Fedora wants to reduce that kind of > thing. > > This summer I intend to try and patch the makefile so that it has the > option of using system sqlite as that is better on the security end > (regarding flaws in sqlite) and will try to get it upstream. The same is true with the PHP sqlite module (both the "old" one, included in PHP sources of 5.x, and the "new" one that uses PDO) :-( I really wonder why authors choose to go in this direction... If anyone wants to take a go at ripping out the sqlite sources from both the PHP and perl modules, and have them link against shared libraries instead, that would be great! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 2.01 1.72 1.10 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 11:26:47 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 13:26:47 +0200 Subject: Request for review Glide3 (newer upstream) x86_64 compile wanted In-Reply-To: <42AC1318.9010406@hhs.nl> References: <42AC11D7.3030502@hhs.nl> <42AC1318.9010406@hhs.nl> Message-ID: <20050708132647.47497fd8@python2> Hans de Goede wrote : > No reviews possible for now as I don't have any ftpspace to put the SRPM > (grr). You could maybe just put the spec file, eventual patches, and as long as the main Source: points to a valid absolute URL, then we can still rebuild, test and review the package. Let me know (don't hesitate to email me privately) if you still need x86_64 testing for Glide3. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.10 0.60 0.84 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 11:41:29 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 13:41:29 +0200 Subject: Request for Review, Sponsorship: trickle, libevent In-Reply-To: <20050617134835.47f37f87@nausicaa.camperquake.de> References: <1118935319.9569.42.camel@wombat.tiptoe.de> <42B1A56E.2060501@di.uminho.pt> <1119008707.17422.15.camel@gibraltar.stuttgart.redhat.com> <20050617134835.47f37f87@nausicaa.camperquake.de> Message-ID: <20050708134129.3178a4b2@python2> Ralf Ertzinger wrote : > Nils Philippsen wrote: > > > hmm, I have no problem with someone else maintaining libevent, as I > > wanted to have it only as a base for trickle anyway. Unfortunately, the > > discussion seems to have stalled after some talking about %ghost, %check > > and so forth. It'd be great if we resolve this. > > %check has been fixed in my local copy, %ghost was for the tor package. > I am a little stressed at the moment, but I'll upload the fixed libevent > for checking today. News on this? I'd definitely be willing to review the packages. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 2.25 1.96 1.50 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 11:51:34 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 13:51:34 +0200 Subject: Nexuiz In-Reply-To: <20050615102150.GB4542@lisas.de> References: <20050609082426.GA8518@lisas.de> <1118307016.25537.10.camel@laptop.mpeters.local> <20050609085606.GA22286@lisas.de> <20050609110744.46c22d68.bugs.michael@gmx.net> <20050609102529.GA30500@lisas.de> <20050615102150.GB4542@lisas.de> Message-ID: <20050708135134.01e4a228@python2> Adrian Reber wrote : > On Thu, Jun 09, 2005 at 12:25:29PM +0200, Adrian Reber wrote: > > http://lisas.de/~adrian/rpm/nexuiz-1.0-2/ > > So... Is the nexuiz package ready to be approved or does it need more > work? Attached is an updated spec (too many changes for a readable patch) : - Better descriptions, as already suggested by Michael A. Peters. - Consistency between "%{name}" and "nexuiz" usage in the spec. - Consistency between tabs and spaces in the spec. - Fix cat appends that could break with -bi --short-circuit. - Simplify passing the optflags (without requiring patching). - Version the makefile patch's name. - Patch the default basedir to avoid the need for wrapper scripts. Further changes I'd like to make : - Maybe the nexus-data could be an independant package, and the others be built from the "nexuizenginesource20050530.zip" source. This would prevent bugfixes to the binaries to force a 150MB data update to mirrors and users (definitely a good thing!), and also allow sharing the data between FC archs and releases. Objections? Comments? - The sources contain icons in a variety of different resolutions. What is the proper way of using the icon cache etc. now? Would it be worth including more than one? I've tested the package with my changes... but without accelerated 3D available, so it "works", but I couldn't actually play the game :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 2.98 1.93 1.02 -------------- next part -------------- A non-text attachment was scrubbed... Name: nexuiz-1.0-basedir.patch Type: application/octet-stream Size: 332 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nexuiz-1.0-makefile.patch Type: application/octet-stream Size: 916 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nexuiz.spec Type: application/octet-stream Size: 3089 bytes Desc: not available URL: From oliver at linux-kernel.at Fri Jul 8 12:43:13 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 14:43:13 +0200 Subject: Request for Review, Sponsorship: trickle, libevent In-Reply-To: <20050708134129.3178a4b2@python2> References: <1118935319.9569.42.camel@wombat.tiptoe.de> <42B1A56E.2060501@di.uminho.pt> <1119008707.17422.15.camel@gibraltar.stuttgart.redhat.com> <20050617134835.47f37f87@nausicaa.camperquake.de> <20050708134129.3178a4b2@python2> Message-ID: <42CE74E1.4010202@linux-kernel.at> On 07/08/2005 01:41 PM, Matthias Saou wrote: > Ralf Ertzinger wrote : > > >>Nils Philippsen wrote: >> >> >>>hmm, I have no problem with someone else maintaining libevent, as I >>>wanted to have it only as a base for trickle anyway. Unfortunately, the >>>discussion seems to have stalled after some talking about %ghost, %check >>>and so forth. It'd be great if we resolve this. >> >>%check has been fixed in my local copy, %ghost was for the tor package. >>I am a little stressed at the moment, but I'll upload the fixed libevent >>for checking today. > > > News on this? I'd definitely be willing to review the packages. But there allready is a libevent package in FE... Best, Oliver From j.w.r.degoede at hhs.nl Fri Jul 8 12:48:21 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 08 Jul 2005 14:48:21 +0200 Subject: Request for review Glide3 (newer upstream) x86_64 compile wanted In-Reply-To: <20050708132647.47497fd8@python2> References: <42AC11D7.3030502@hhs.nl> <42AC1318.9010406@hhs.nl> <20050708132647.47497fd8@python2> Message-ID: <42CE7615.5000000@hhs.nl> Matthias Saou wrote: > Hans de Goede wrote : > > >>No reviews possible for now as I don't have any ftpspace to put the SRPM >>(grr). > > > You could maybe just put the spec file, eventual patches, and as long as > the main Source: points to a valid absolute URL, then we can still > rebuild, test and review the package. > > Let me know (don't hesitate to email me privately) if you still need > x86_64 testing for Glide3. > > Matthias > Thanks for the offer, I've already solved the problem by getting myself an athlon64 motherboard + cpu, which is just about as expensive as a year of descent webhosting with enough space :) Regards, Hans From oliver at linux-kernel.at Fri Jul 8 12:52:21 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 14:52:21 +0200 Subject: [Fwd: Request for review: libdnet] Message-ID: <42CE7705.2090002@linux-kernel.at> This mail should have it's way made here, not to extras-commits. :-/ However, here we go now... -------- Original Message -------- Subject: Request for review: libdnet Date: Fri, 08 Jul 2005 14:51:24 +0200 From: Oliver Falk To: Fedora Extras CVS commits Summary: Simple portable interface to lowlevel networking routines Description: libdnet provides a simplified, portable interface to several low-level networking routines, including network address manipulation, kernel arp(4) cache and route(4) table lookup and manipulation, network firewalling (IP filter, ipfw, ipchains, pf, ...), network interface lookup and manipulation, raw IP packet and Ethernet frame, and data transmission. SRPM & SPEC: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet I'd like to include libdnet as a prerequisite for scanssh. scanssh also uses libevent, but this is allready in FE. Please review/approve. Merci, Oliver From oliver at linux-kernel.at Fri Jul 8 12:56:41 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 14:56:41 +0200 Subject: Request for review: bwm-ng Message-ID: <42CE7809.3090202@linux-kernel.at> bwm-ng is still in my pipe and here we go: Summary: A bandwidth monitor Description A small and simple curses base bandwidth monitor. No big features. SPEC & SRPM: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/bwm-ng (bwm-ng uses the libstatgrab package, which was included today!). Please review/approve. Merci, Oliver From oliver at linux-kernel.at Fri Jul 8 13:41:58 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 15:41:58 +0200 Subject: libevent (WAS: Re: Request for Review, Sponsorship: trickle, libevent) In-Reply-To: <42CE74E1.4010202@linux-kernel.at> References: <1118935319.9569.42.camel@wombat.tiptoe.de> <42B1A56E.2060501@di.uminho.pt> <1119008707.17422.15.camel@gibraltar.stuttgart.redhat.com> <20050617134835.47f37f87@nausicaa.camperquake.de> <20050708134129.3178a4b2@python2> <42CE74E1.4010202@linux-kernel.at> Message-ID: <42CE82A6.1060607@linux-kernel.at> On 07/08/2005 02:43 PM, Oliver Falk wrote: > On 07/08/2005 01:41 PM, Matthias Saou wrote: > >> Ralf Ertzinger wrote : >> >> >>> Nils Philippsen wrote: >>> >>> >>>> hmm, I have no problem with someone else maintaining libevent, as I >>>> wanted to have it only as a base for trickle anyway. Unfortunately, the >>>> discussion seems to have stalled after some talking about %ghost, >>>> %check >>>> and so forth. It'd be great if we resolve this. >>> >>> >>> %check has been fixed in my local copy, %ghost was for the tor package. >>> I am a little stressed at the moment, but I'll upload the fixed libevent >>> for checking today. >> >> >> >> News on this? I'd definitely be willing to review the packages. > > > But there allready is a libevent package in FE... Unfortunately, the package is in FE devel (package by Ralf Ertzinger), but it doesn't show up on download.fedora.redhat.com and is not listed on bugzilla. Ralf, don't you maintain the package any more? Have you ever requested a build??? Best, Oliver From mfleming at enlartenment.com Fri Jul 8 13:56:18 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Fri, 8 Jul 2005 23:56:18 +1000 Subject: Request for review / approval: mod_security. Message-ID: <20050708235618.5416729e.mfleming@enlartenment.com> Hi folks, I've undoubtedly put this one up before a while back, but I've made a couple of small changes and added some useful rules in the default config. Therefore I'm putting this up for further review and approval (I don't recall seeing much last time - I felt such a package would generate more interest :-)). Name: mod_security Summary: Security module for the Apache HTTP Server Description: ModSecurity is an open source intrusion detection and prevention engine for web applications. It operates embedded into the web server, acting as a powerful umbrella - shielding web applications from attacks. SRPM: http://www.enlartenment.com/extras/mod_security/mod_security-1.8.7-2.src.rpm Please have a look and feel free to send feedback or improvements. Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From fedora at camperquake.de Fri Jul 8 14:09:31 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 8 Jul 2005 16:09:31 +0200 Subject: libevent (WAS: Re: Request for Review, Sponsorship: trickle, libevent) In-Reply-To: <42CE82A6.1060607@linux-kernel.at> References: <1118935319.9569.42.camel@wombat.tiptoe.de> <42B1A56E.2060501@di.uminho.pt> <1119008707.17422.15.camel@gibraltar.stuttgart.redhat.com> <20050617134835.47f37f87@nausicaa.camperquake.de> <20050708134129.3178a4b2@python2> <42CE74E1.4010202@linux-kernel.at> <42CE82A6.1060607@linux-kernel.at> Message-ID: <20050708160931.65cbdbdb@nausicaa.camperquake.de> Hi. Oliver Falk wrote: > Ralf, don't you maintain the package any more? Have you ever requested > a build??? I have checked in the package two days ago (I think), but I have not requested a build so far. Things are a bit sluggish on my end, this will change soon. Sorry for that. -- "640K ought to be enough for anybody." -- Bill Gates, 1981 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 14:12:17 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 16:12:17 +0200 Subject: Nexuiz, continued Message-ID: <20050708161217.543f9291@python2> Hi, What I feared happened : I ended up with and unrecognizable nexuiz.spec file after starting making changes to Adian's spec :-/ Since the last email I sent earlier today, the major changes are : - Update to 1.1. - Split the program and the data into two separate packages. - Use the correct icons, with multi-resolution ico -> png trick. You can find the files here : http://ftp.es6.freshrpms.net/tmp/extras/ Adrian, I don't know if you'll agree to these changes or not. I hope you won't see this as an attempt to take over the package either, as it is indeed more than just "suggestions" or "reviewing"... I just get carried away sometimes, sorry. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 2.43 1.62 1.12 From oliver at linux-kernel.at Fri Jul 8 14:20:01 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 16:20:01 +0200 Subject: Request for review / approval: mod_security. In-Reply-To: <20050708235618.5416729e.mfleming@enlartenment.com> References: <20050708235618.5416729e.mfleming@enlartenment.com> Message-ID: <42CE8B91.5010800@linux-kernel.at> Hi Michael! On 07/08/2005 03:56 PM, Michael Fleming wrote: > Hi folks, > > I've undoubtedly put this one up before a while back, but I've made a couple > of small changes and added some useful rules in the default config. > > Therefore I'm putting this up for further review and approval (I don't > recall seeing much last time - I felt such a package would generate more > interest :-)). > > Name: mod_security > > Summary: Security module for the Apache HTTP Server > > Description: > > ModSecurity is an open source intrusion detection and prevention engine for > web applications. It operates embedded into the web server, acting as a > powerful umbrella - shielding web applications from attacks. > > SRPM: > http://www.enlartenment.com/extras/mod_security/mod_security-1.8.7-2.src.rpm > > Please have a look and feel free to send feedback or improvements. You don't need an approval if the package was allready approved and is in cvs... Spec looks OK for me and and it seems you havn't change very much... But OK, I'd like to mention a few things: - BuildRoot, as described in the PackagingGuidelines, pls. (http://fedoraproject.org/wiki/PackagingGuidelines). %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - Why does the new package not depend on http(/-devel) >= 2.0.38, as the old package in CVS does? - Don't forget the %{dist} tag in the release, if you intend to cvs commit this. - setup can be written as setup -q (the -n modsecurity-%{version} is not needed) Best, Oliver From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 14:25:17 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 16:25:17 +0200 Subject: nvu In-Reply-To: <42CD8EAF.8020600@redhat.com> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> <42C7D246.7070905@redhat.com> <20050707214937.7fc3ce96@python2> <42CD8EAF.8020600@redhat.com> Message-ID: <20050708162517.2f5e21e9@python2> Christopher Aillon wrote : > >The only major blocker I saw was that without --disable-crypto, the build > >failed on FC4 i386, on a .h file which is identical to the one in the > >1.0.4 firefox tree, go figure. > > > > > Interesting -- got a build log? Crypto is probably something we'd want > to support here for pushing to some things such as krb5 realms, etc. > (not sure if that's even an option in today's nvu, but still...) Check the new nvu-1.0-0.1.i386-crypto-failed.log.gz here : http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/4/nvu/ > I'd suggest: > > Name=Nvu Web Authoring Tool > GenericName=Web Authoring Tool OK, changed. > Do we have all the pango patches we need to --enable-pango? Not sure whether those made it into nvu's branch or not, but we should add them if not. Especially so for rawhide, since the removal of xft caused text to not render properly in firefox without the latest patch in the rawhide RPM (firefox-1.0-pango-cairo.patch). > > You'll probably also need some of the patches requried to compile firefox on rawhide (the gcc4 patches, prdtoa patches, etc). > > I'll do a more formal review when you're ready. Well, from my POV the package is "ready" since it builds fine on FC4 and runs fine based on the testing I've done. But checking made by people who know the problems that might be encountered (pango for instance), would be a good thing, so don't hesitate to do some testing, and comment :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 2.08 2.14 2.27 From oliver at linux-kernel.at Fri Jul 8 14:25:53 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jul 2005 16:25:53 +0200 Subject: libevent (WAS: Re: common tobuild,1.1853,1.1854) In-Reply-To: <200507081420.j68EKgMh031678@cvs-int.fedora.redhat.com> References: <200507081420.j68EKgMh031678@cvs-int.fedora.redhat.com> Message-ID: <42CE8CF1.4000604@linux-kernel.at> On 07/08/2005 04:20 PM, Ralf Ertzinger (ertzing) wrote: > Author: ertzing > > Update of /cvs/extras/common > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31661 > > Modified Files: > tobuild > Log Message: > request build of rpms/libevent/devel libevent-1_1a-2_fc5 for devel > > > Index: tobuild > =================================================================== > RCS file: /cvs/extras/common/tobuild,v > retrieving revision 1.1853 > retrieving revision 1.1854 > diff -u -r1.1853 -r1.1854 > --- tobuild 8 Jul 2005 10:15:30 -0000 1.1853 > +++ tobuild 8 Jul 2005 14:20:40 -0000 1.1854 > @@ -28,3 +28,4 @@ > mschwendt devel/wesnoth wesnoth-0_9_3-1_fc5 devel > mschwendt devel/screem screem-0_14_1-1_fc5 devel > mschwendt devel/anjuta anjuta-1_2_3-2_fc5 devel > +ertzing rpms/libevent/devel libevent-1_1a-2_fc5 devel Ah, here we go... :-) -of From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 14:38:23 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 16:38:23 +0200 Subject: OpenGroupware? In-Reply-To: <20050706200356.GB29034@osiris.silug.org> References: <20050706200356.GB29034@osiris.silug.org> Message-ID: <20050708163823.5e42b715@python2> Steven Pritchard wrote : > Is anyone working on cleaning up OpenGroupware for Extras? > > If not, I will probably have to. (I have a client who wants it set > up.) Of course, I'd rather just review someone else's work... ;-) Looks like you could give it a shot :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.36 0.52 1.25 From ivazquez at ivazquez.net Fri Jul 8 14:46:56 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 08 Jul 2005 10:46:56 -0400 Subject: Request for review: libifp In-Reply-To: <20050708115510.4956eb28@python2> References: <1120769439.9522.6.camel@ignacio.ignacio.lan> <1120772774.2903.47.camel@localhost.localdomain> <1120774599.9522.14.camel@ignacio.ignacio.lan> <1120805637.2789.7.camel@localhost.localdomain> <20050708115510.4956eb28@python2> Message-ID: <1120834016.9522.22.camel@ignacio.ignacio.lan> On Fri, 2005-07-08 at 11:55 +0200, Matthias Saou wrote: > Does anyone have plans to also include a GUI application that uses libifp? > Last time I searched around, most of them still relied on much older > libifp versions (basically running the binaries instead of using the new > lib), and/or were in very early stages. I've been thinking about a Rhythmbox plugin, but we'll have to see where that goes as my time is stretched out fairly thin as-is. > Up to now, I've always used libifp only once on each iRiver device I've > had, to just flash a USB Mass Storage firmware to the device, but the main > drawback is that song ordering in directories is pretty much randomly set > when using UMS (i.e. not alphabetical), which isn't the case with the > "manager" (so, using libifp) from what I've read. Unfortunately libifp doesn't have the ability to reorder songs yet. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 adrian at lisas.de Fri Jul 8 14:45:15 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 8 Jul 2005 16:45:15 +0200 Subject: Nexuiz, continued In-Reply-To: <20050708161217.543f9291@python2> References: <20050708161217.543f9291@python2> Message-ID: <20050708144515.GB7800@lisas.de> On Fri, Jul 08, 2005 at 04:12:17PM +0200, Matthias Saou wrote: > Since the last email I sent earlier today, the major changes are : > - Update to 1.1. > - Split the program and the data into two separate packages. I would have also split the package if upstream already had provided two sources. But now that you have already done it and documented it very nicely in the spec file I see no problem at all with it. > - Use the correct icons, with multi-resolution ico -> png trick. > > You can find the files here : > http://ftp.es6.freshrpms.net/tmp/extras/ > > Adrian, I don't know if you'll agree to these changes or not. I hope > you > won't see this as an attempt to take over the package either, as it is > indeed more than just "suggestions" or "reviewing"... I just get > carried > away sometimes, sorry. No problem. We just maintain it together. So do I now post the same package you have just posted or do I now review your changes... I will have a look at it and come back later. Adrian From caillon at redhat.com Fri Jul 8 15:05:51 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 08 Jul 2005 11:05:51 -0400 Subject: nvu In-Reply-To: <20050708162517.2f5e21e9@python2> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> <42C7D246.7070905@redhat.com> <20050707214937.7fc3ce96@python2> <42CD8EAF.8020600@redhat.com> <20050708162517.2f5e21e9@python2> Message-ID: <42CE964F.3000603@redhat.com> On 07/08/2005 10:25 AM, Matthias Saou wrote: >Christopher Aillon wrote : > > > >>>The only major blocker I saw was that without --disable-crypto, the build >>>failed on FC4 i386, on a .h file which is identical to the one in the >>>1.0.4 firefox tree, go figure. >>> >>> >>> >>> >>Interesting -- got a build log? Crypto is probably something we'd want >>to support here for pushing to some things such as krb5 realms, etc. >>(not sure if that's even an option in today's nvu, but still...) >> >> > >Check the new nvu-1.0-0.1.i386-crypto-failed.log.gz here : > >http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/4/nvu/ > > In file included from ../../../../dist/private/nss/nsspki1.h:57, from nsspki.h:56, from asymmkey.c:39: ../../../../dist/private/nss/oiddata.h:46: error: array type has incomplete element type This was a bug in upstream's source, with the patch in firefox. See https://bugzilla.mozilla.org/show_bug.cgi?id=284386 This brings up an interesting point in that some patches I used to have applied and then removed since they were upstreamed in the firefox branch may not have made it to the nvu branch :-( Some really should go through and make sure that all the fedora patches in the firefox 1.0 series of packages (e.g. 1.0, 1.0.1, ... 1.0.4) have equivalent patches in the nvu package. They exist for reasons. This is the porting work that I mentioned earlier and may not be trivial. The spec you provided is fairly easy to generate, its just not something I would have felt comfortable putting into extras as-is -- it should have the rest of the patches as well as I mentioned in my previous post. > > >>I'd suggest: >> >>Name=Nvu Web Authoring Tool >>GenericName=Web Authoring Tool >> >> > >OK, changed. > > > >>Do we have all the pango patches we need to --enable-pango? Not sure whether those made it into nvu's branch or not, but we should add them if not. Especially so for rawhide, since the removal of xft caused text to not render properly in firefox without the latest patch in the rawhide RPM (firefox-1.0-pango-cairo.patch). >> >>You'll probably also need some of the patches requried to compile firefox on rawhide (the gcc4 patches, prdtoa patches, etc). >> >>I'll do a more formal review when you're ready. >> >> > >Well, from my POV the package is "ready" since it builds fine on FC4 and >runs fine based on the testing I've done. But checking made by people who >know the problems that might be encountered (pango for instance), would be >a good thing, so don't hesitate to do some testing, and comment :-) > > The firefox 1.0 version also builds with --enable-pango, but its not really functional. You probably need the patches from the firefox version applied, those haven't been checked in on the FIREFOX_1_0_1_20050124_AVIARY_BRANCH yet and I doubt they made it into nvu's source (but I could be wrong). From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 15:29:33 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 17:29:33 +0200 Subject: Nexuiz, continued In-Reply-To: <20050708144515.GB7800@lisas.de> References: <20050708161217.543f9291@python2> <20050708144515.GB7800@lisas.de> Message-ID: <20050708172933.722d0f00@python2> Adrian Reber wrote : > No problem. We just maintain it together. So do I now post the same > package you have just posted or do I now review your changes... > I will have a look at it and come back later. I guess we'll need an APPROVED like : Maintained by : Adrian & Matthias Reviewed by : Matthias & Adrian :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.42 0.20 0.29 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 16:20:07 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 18:20:07 +0200 Subject: nvu In-Reply-To: <42CE964F.3000603@redhat.com> References: <1120377429.3772.410.camel@potter.soho.bytebot.net> <42C7D246.7070905@redhat.com> <20050707214937.7fc3ce96@python2> <42CD8EAF.8020600@redhat.com> <20050708162517.2f5e21e9@python2> <42CE964F.3000603@redhat.com> Message-ID: <20050708182007.26e4b43f@python2> Christopher Aillon wrote : > In file included from ../../../../dist/private/nss/nsspki1.h:57, > from nsspki.h:56, > from asymmkey.c:39: > ../../../../dist/private/nss/oiddata.h:46: error: array type has > incomplete element type > > This was a bug in upstream's source, with the patch in firefox. See > https://bugzilla.mozilla.org/show_bug.cgi?id=284386 > > This brings up an interesting point in that some patches I used to have > applied and then removed since they were upstreamed in the firefox > branch may not have made it to the nvu branch :-( Yeah... when I had a quick look, I saw that all those files were tagged as firefox 1.0, vs. 1.0.4 being the latest. > Some really should go through and make sure that all the fedora patches > in the firefox 1.0 series of packages (e.g. 1.0, 1.0.1, ... 1.0.4) have > equivalent patches in the nvu package. They exist for reasons. This is > the porting work that I mentioned earlier and may not be trivial. The > spec you provided is fairly easy to generate, its just not something I > would have felt comfortable putting into extras as-is -- it should have > the rest of the patches as well as I mentioned in my previous post. Interesting point indeed. Not being a developer, the work I do consists only of packaging and integrating (desktop files, init scripts etc.) software, not fixing it along the way. So for me, if the nvu 1.0 sources have bugs, I'll report them and include eventual backported fixes, but definitely won't (because I can't) fix them myself... For me, providing the same level of quality than upstream (i.e. no more or less bugs) in an easy to install and well integrated manner should be sufficient for Fedora Extras. Obviously, this is arguable. But from there, the software should get wider usage, and proxying problems to upstream, then including the fixes they come up with, should be enough to keep end users happy. In this particular case, I know I won't be using nvu regularly, if at all actually. But I was a bit disappointed to not having seen it in Extras yet, and heard back from people I know who unpacked the pre-compiled binaries on their Fedora systems. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.38 0.19 0.24 From ville.skytta at iki.fi Fri Jul 8 16:46:44 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 08 Jul 2005 19:46:44 +0300 Subject: Review: libapreq2 In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <1120841204.2892.16.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > libapreq2: > Library for manipulating client request data via the Apache API Notes/suggestions: - Hardcodes "5.8.6" in %install - There's a _huge_ leak in upstream 2.05's Apache2::Upload, a fix for it was committed to svn today, I believe. I would suggest waiting for 2.06; the rest of the stuff in this 39-package submission will take a while anyway to review... - I'd suggest splitting the Perl stuff intoa "perl-libapreq2" subpackage (I also add "perl-libapreq" for hysterical raisins so that an app which can use both mod_perl 1 or 2 can use that as a dependency). - Add a /etc/httpd/conf.d/ snippet so that the module is loaded when httpd starts. - Add a dependency on httpd-mmn, see mod_perl and mod_python in Core. - If you're not targetting < FC2, LD_RUN_PATH stuff in %build, "|| :" after %check, and the definition of perl_vendorarch at the top are not needed. - Versioned dependencies would be nice, at least for mod_perl. - I think it's very unlikely that someone would find static libs of this useful. Or at least the Apache module. - condrestart httpd at first install's %post, and on all %postun? - NOTICE must be in the distribution, some other docs could as well. I've been following and packaging this for a long time, and my package of it is at http://cachalot.mine.nu/4/SRPMS/libapreq2-2.05-0.6.src.rpm It implements the above and some more. I would be happy to maintain this too, but have been waiting for 2.06 due to the above mentioned leak. Would you like me to maintain this? If so, just review the package above, and I'll take care of adding it to CVS and not building before the Apache2::Upload is fixed by patching or updating. From ville.skytta at iki.fi Fri Jul 8 16:47:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 08 Jul 2005 19:47:56 +0300 Subject: Non-review: perl-IO-stringy In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <1120841276.2892.18.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > perl-IO-stringy: > I/O on in-core objects like strings and arrays Already in Extras. From ville.skytta at iki.fi Fri Jul 8 17:02:37 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 08 Jul 2005 20:02:37 +0300 Subject: Review: perl-ExtUtils-XSBuilder In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <1120842157.2892.34.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > perl-ExtUtils-XSBuilder: > Modules that parse C header files and create XS glue code Notes: - Missing "Requires: perl(Tie::IxHash)" - not a hard dep, but for the module to be fully useful. I don't think adding would cause problems. - noarch package -> no need for CFLAGS or OPTIMIZE in %build - No need to define perl_vendorarch or "|| :" after %check if you're targetting > FC2. - Installs executable *.pm and *.pod -> easyfix: "find . -type f | xargs chmod -x" in %prep - README contains copyright/licensing info, suggesting adding it. Go ahead and import to CVS and fix what you find worth fixing of the above, and I'll recheck. From ville.skytta at iki.fi Fri Jul 8 17:12:10 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 08 Jul 2005 20:12:10 +0300 Subject: Review: perl-Tie-DBI In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <1120842730.2892.39.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > perl-Tie-DBI: > Tie hashes to DBI relational databases Notes: - perl_vendorlib definition and "|| :" after %check not needed in > FC2 - CFLAGS and OPTIMIZE not needed for noarch - Suggested %description: This distribution contains Tie::DBI and Tie::RDBM, two modules that allow you to tie associative arrays to relational databases using the DBI library. The hash is tied to a table in a local or networked database. Reading from the hash retrieves values from the datavbase. Storing into the hash updates the database (if you have sufficient privileges). Go ahead and import to CVS and fix what you find worth fixing of the above, and I'll recheck. From ville.skytta at iki.fi Fri Jul 8 17:18:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 08 Jul 2005 20:18:04 +0300 Subject: Request for review: perl-Maypole (and friends) In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <1120843084.2892.46.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > So, I am requesting review for perl-Maypole, and the 39 other packages > that it needed as dependencies. Now, before everyone freaks and runs the > other direction, the vast majority of these packages are perl noarch, > straight off the template. Most of the packages seem to have some _cosmetic_ issues, so I think it'll suffice to mention them once here, and not repeat in all reviews: - CFLAGS and OPTIMIZE not needed for noarch - No need to define perl_vendor* or use "|| :" in %check in > FC2 - LD_RUN_PATH hacks in %build not needed in > FC1 No need to rush and fix these now if you're not bored :). That can be done after someone approves the packages. From chris at chrisgrau.com Fri Jul 8 17:24:25 2005 From: chris at chrisgrau.com (Chris Grau) Date: Fri, 8 Jul 2005 10:24:25 -0700 Subject: Request for review / approval: frotz. Message-ID: <20050708172425.GA31553@chrisgrau.com> Hi, This is my first attempt at submitting a package to Fedora Extras. I hope I'm going about it the right way. Name: frotz Summary: Interpreter for Infocom and other Z-machine games Description: Frotz is an interpreter for Infocom games and other Z-machine games. It complies with standard 1.0 of Graham Nelson's specification. http://www.chrisgrau.com/packages/frotz/frotz.spec http://www.chrisgrau.com/packages/frotz/frotz-2.43-1.src.rpm Thanks. -chris From ermeyers at adelphia.net Fri Jul 8 17:32:43 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 8 Jul 2005 13:32:43 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507081332.58353.ermeyers@adelphia.net> Gentlemen, I'm just getting started familiarizing myself with the Fedora-Extras project. I had a chat with Seth Vidal on #fedora-extras about what I'm presenting here. I went to http://fedoraproject.org/extras/4/i386/repodata/ and saw the following matter. RepoView * Indexed Packages: 1251 * Available Architectures: i386, noarch * Total groups: 22 First notice, Indexed Packages: 1251. Second notice, Total groups: 22. The RepoView groups are listed here and enumerated: ___Sidebar___ ___Lower___ 1. * __latest__ * Last 30 Packages Updated 2. * __nogroup__ * Packages not in Groups 3. * authoring-and-pub... * Authoring and Publishing 4. * development-tools * Development Tools 5. * editors * Editors 6. * engineering-and-s... * Engineering and Scientific 7. * ftp-server * FTP Server 8. * games * Games and Entertainment 9. * gnome-desktop * GNOME Desktop Environment 10. * graphical-internet * Graphical Internet 11. * graphics * Graphics 12. * mail-server * Mail Server 13. * news-server * News Server 14. * office * Office/Productivity 15. * sound-and-video * Sound and Video 16. * system-tools * System Tools 17. * text-internet * Text-based Internet 18. * web-server * Web Server 19. * xfce-desktop * XFCE 20. * xfce-software-dev... * XFCE Software Development Under category #2 "__nogroup__" or "Packages not in Groups," I found 1031 packages listed. That is too many, in my oppinion, 1031 of 1251. Why does it say 22 groups, when only 20 groups are listed? I'm attempting to assist in remedying these two problems. And Seth steered me to the comps.xml file, which has the following list of groups. 1. Administration Tools 2. Authoring and Publishing 3. Base 4. Core 5. DNS Name Server 6. Development Libraries 7. Development Tools 8. Dialup Networking Support 9. Editors 10. Engineering and Scientific 11. FTP Server 12. GNOME Desktop Environment 13. GNOME Software Development 14. Games and Entertainment 15. Graphical Internet 16. Graphics 17. KDE (K Desktop Environment) 18. KDE Software Development 19. Legacy Network Server 20. Mail Server 21. MySQL Database 22. Network Servers 23. News Server 24. Office/Productivity 25. PostgreSQL Database 26. Printing Support 27. Ruby 28. Server Configuration Tools 29. Sound and Video 30. System Tools 40. Text-based Internet 41. Web Server 42. Windows File Server 43. X Software Development 44. X Window System 45. XEmacs 46. XFCE 47. XFCE Software Development 48. Desktops 49. Development This comps.xml based list of groups might take a chunk out of the large number of unassigned packages. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joelwreed at comcast.net Fri Jul 8 17:20:58 2005 From: joelwreed at comcast.net (joel reed) Date: Fri, 8 Jul 2005 13:20:58 -0400 Subject: Request for review: libxslt-plugin-regexp and libxslt-plugin-dates-and-times Message-ID: <20050708172058.GA11437@comcast.net> Can the following two libxslt plugins be added to fedora extras? They add support for a few http://exslt.org extension functions to libxslt. 1. regular-expressions Implements regexp:test, regexp.match, and regexp:replace using PCRE. 2. dates-and-times Implements format:date using libgcj. src.rpm and spec files: http://home.comcast.net/~joelwreed/libxslt-plugin-regexp-0.5-1.src.rpm http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times-0.2-1.src.rpm http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times.spec Thanks for taking the time to review these plugins. At some point I'd need Fedora Extras CVS write access I guess. Daniel Veillard has kindly offered to "be the primary reviewer and the approver of your package." Many thanks to Daniel for the libxslt library. jr From jspaleta at gmail.com Fri Jul 8 17:48:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 8 Jul 2005 13:48:53 -0400 Subject: Request for additional reviews of glabels. In-Reply-To: <1120796850.30532.309.camel@mccallum.corsepiu.local> References: <604aa791050707145489c16c0@mail.gmail.com> <1120796850.30532.309.camel@mccallum.corsepiu.local> Message-ID: <604aa791050708104817990b43@mail.gmail.com> On 7/8/05, Ralf Corsepius wrote: > On Thu, 2005-07-07 at 17:54 -0400, Jeff Spaleta wrote: > > Now that glabels is in extras cvs, anyone have any additional comments > > before I request builds? > Two minor issues: > > %doc %{_mandir}/man1/glabels.1* > The %doc on this line is redundant (files under %_mandir automatically > are docs). I'll make that correction in the cvs spec file so its ready to roll in the next build. > > %doc %{_datadir}/gnome/help/glabels/ > I would not mark "help files" %doc, because references to them are not > unlikely to be hard-coded into the application. So, if a user installs > the package with "--excludedocs", he could end up with a broken > application (I haven't actually tried with this package). I'm not sure about what the most correct thing to do in this case is. It doesnt appear to break anything for this appliction specifically, as far as I've tried. I'll gladly conform to whatever the seemingly rational consensous is on the subject of marking help files as docs or not. -jef From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 17:52:46 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 19:52:46 +0200 Subject: Nexuiz In-Reply-To: <20050609110744.46c22d68.bugs.michael@gmx.net> References: <20050609082426.GA8518@lisas.de> <1118307016.25537.10.camel@laptop.mpeters.local> <20050609085606.GA22286@lisas.de> <20050609110744.46c22d68.bugs.michael@gmx.net> Message-ID: <20050708195246.3b101f3d@python2> Michael Schwendt wrote : > > > Requires: %{name}-data libz.so.1 libvorbis.so.0 libvorbisfile.so.3 > > > Requires: libjpeg.so.62 > > > > > > You can drop the specific library requires, rpm should figure that out. > > > > But rpm doesn't. The binary isn't linked against these libraries but > > tries to load them during runtime. > > That's something a comment in the spec file ought to explain. It also > means that these explicit soname dependencies may need to be revisited > periodically. And this actually requires a better solution, as those provides are different on 64bit systems, thus those requirements can't be met. I'd put "zlib libvorbis libjpeg" for now. Yeah, we'll be in trouble when one of those libraries changes its major number... but I can't think of any clean solution anyway. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.43 0.42 0.37 From ivazquez at ivazquez.net Fri Jul 8 18:10:51 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 08 Jul 2005 14:10:51 -0400 Subject: Request for review: libxslt-plugin-regexp and libxslt-plugin-dates-and-times In-Reply-To: <20050708172058.GA11437@comcast.net> References: <20050708172058.GA11437@comcast.net> Message-ID: <1120846252.9522.34.camel@ignacio.ignacio.lan> On Fri, 2005-07-08 at 13:20 -0400, joel reed wrote: > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec - Versions in Requires, BuildRequires, and %description need to be fixed up - Either add "Requires(post): /sbin/ldconfig \nRequires(postun): /sbin/ldconfig" or change the %post[un] lines to "%... -p /sbin/ldconfig" - Line spacing in %install and %files is odd - Package doesn't own %{_libdir}/libxslt ! %description says that PCRE is required, but there's no BR for it - %changelog entry is missing name/version at the end > http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times.spec Same issues as above except s/PCRE/gcj/. > Thanks for taking the time to review these plugins. At some point I'd > need Fedora Extras CVS write access I guess. https://admin.fedora.redhat.com/accounts/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Fri Jul 8 18:20:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 13:20:56 -0500 Subject: Non-review: perl-IO-stringy In-Reply-To: <1120841276.2892.18.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120841276.2892.18.camel@localhost.localdomain> Message-ID: <1120846856.9303.114.camel@localhost.localdomain> On Fri, 2005-07-08 at 19:47 +0300, Ville Skytt? wrote: > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > perl-IO-stringy: > > I/O on in-core objects like strings and arrays > > Already in Extras. Whoops. I figured I would miss one or two. :/ ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 8 18:32:47 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 13:32:47 -0500 Subject: Review: libapreq2 In-Reply-To: <1120841204.2892.16.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120841204.2892.16.camel@localhost.localdomain> Message-ID: <1120847567.9303.125.camel@localhost.localdomain> On Fri, 2005-07-08 at 19:46 +0300, Ville Skytt? wrote: > I've been following and packaging this for a long time, and my package > of it is at http://cachalot.mine.nu/4/SRPMS/libapreq2-2.05-0.6.src.rpm > It implements the above and some more. I would be happy to maintain > this too, but have been waiting for 2.06 due to the above mentioned > leak. Would you like me to maintain this? Please maintain this. :) Review: rpmlint checks: E: libapreq2 outside-libdir-files /etc/httpd/conf.d/apreq.conf Safe to ignore. Good: - Meets naming and packaging guidelines - spec file matches base name - license ok (Apache), license included, matches source - spec file legible, in am.en - sources match upstream - package compiles and builds (x86/fc4) - No missing BuildRequires - no locales - Shared libraries handled properly - static libs handled properly - %post/%postun ok - all directories owned - code not content - %clean ok - macro use is consistent Good work, APPROVED. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From adrian at lisas.de Fri Jul 8 18:32:16 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 8 Jul 2005 20:32:16 +0200 Subject: Nexuiz, continued In-Reply-To: <20050708161217.543f9291@python2> References: <20050708161217.543f9291@python2> Message-ID: <20050708183216.GA24482@lisas.de> On Fri, Jul 08, 2005 at 04:12:17PM +0200, Matthias Saou wrote: > - Use the correct icons, with multi-resolution ico -> png trick. I cannot see an icon in the gnome menu. Adding gtk-update-icon-cache -qf %{_datadir}/icons/hicolor 2>/dev/null || : helped for the icon to be visible. I don't see any other problems and it works pretty good. Should I import it now? Adrian From jamatos at fc.up.pt Fri Jul 8 18:33:34 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 08 Jul 2005 19:33:34 +0100 Subject: Request for review: pytz and python-dateutil References: <42CAF271.50401@cora.nwra.com> <1120649829.15363.77.camel@ignacio.ignacio.lan> Message-ID: Ignacio Vazquez-Abrams wrote: > >> - pyparsing > > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00429.html > http://fedora.ivazquez.net/files/extras/pyparsing-1.3-1.src.rpm It is in my TODO list. LyX 1.3.6 will be out soon and I have been busy doing some last minute fixes. :-) -- Jos? Ab?lio From tcallawa at redhat.com Fri Jul 8 18:42:04 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 13:42:04 -0500 Subject: Review: perl-ExtUtils-XSBuilder In-Reply-To: <1120842157.2892.34.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120842157.2892.34.camel@localhost.localdomain> Message-ID: <1120848124.9303.135.camel@localhost.localdomain> On Fri, 2005-07-08 at 20:02 +0300, Ville Skytt? wrote: > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > perl-ExtUtils-XSBuilder: > > Modules that parse C header files and create XS glue code > > Notes: > - Missing "Requires: perl(Tie::IxHash)" - not a hard dep, but for the > module to be fully useful. I don't think adding would cause problems. > - noarch package -> no need for CFLAGS or OPTIMIZE in %build > - No need to define perl_vendorarch or "|| :" after %check if you're > targetting > FC2. > - Installs executable *.pm and *.pod -> easyfix: > "find . -type f | xargs chmod -x" in %prep > - README contains copyright/licensing info, suggesting adding it. > > Go ahead and import to CVS and fix what you find worth fixing of the > above, and I'll recheck. Made all the changes requested, except I left perl_vendorlib defined. I wasn't sure if you meant that instead of perl_vendorarch or not. Its in CVS. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From wart at kobold.org Fri Jul 8 18:38:50 2005 From: wart at kobold.org (Michael Thomas) Date: Fri, 08 Jul 2005 11:38:50 -0700 Subject: Request for review: tcllib Message-ID: <42CEC83A.9090100@kobold.org> I just discovered that tcllib-1.3 was in FC1 but later removed. I've imported tcllib -1.7 into CVS and now need a review: %description Tcllib, the Tcl Standard Library is a collection of Tcl packages that provide utility functions useful to a large collection of Tcl programmers. The home web site for this code is http://tcllib.sourceforge.net/. At this web site, you will find mailing lists, web forums, databases for bug reports and feature requests, the CVS repository (browsable on the web, or read-only accessible via CVS ), and more. Note: also grab source tarball for more documentation, examples, ... rpmlint gives some warnings such as: : tcllib non-executable-script /usr/share/tcl8.4/tcllib-1.7/pop3/clnt.tcl 0644 E: tcllib script-without-shellbang /usr/share/tcl8.4/tcllib-1.7/math/fourier.tcl ...which can be ignored because these are script libraries, not standalone executable scripts. --Mike From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 8 18:43:49 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jul 2005 20:43:49 +0200 Subject: Nexuiz, continued In-Reply-To: <20050708183216.GA24482@lisas.de> References: <20050708161217.543f9291@python2> <20050708183216.GA24482@lisas.de> Message-ID: <20050708204349.683a9bf4@python2> Adrian Reber wrote : > On Fri, Jul 08, 2005 at 04:12:17PM +0200, Matthias Saou wrote: > > - Use the correct icons, with multi-resolution ico -> png trick. > > I cannot see an icon in the gnome menu. Adding > > gtk-update-icon-cache -qf %{_datadir}/icons/hicolor 2>/dev/null || : > > helped for the icon to be visible. > > I don't see any other problems and it works pretty good. Should I import > it now? Aha! I've been fighting with the icon too for the last 1/2h, thanks for the fix! :-) I see still two problems : - The explicit library name requirements, which break on x86_64 - It's slow (unplayable!) on my AMD64 2800+ w/ Radeon 9200 even in 320x240 The first is a quick fix, but the second... ppracer, neverball etc. work great, I would have thought that from the requirements listed in the Readme my machine would have been sufficiently powerful :-( Other than that, you can consider the packages reviewed and approved! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.24 0.34 0.70 From tcallawa at redhat.com Fri Jul 8 18:45:03 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 13:45:03 -0500 Subject: Review: perl-ExtUtils-XSBuilder In-Reply-To: <1120848124.9303.135.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120842157.2892.34.camel@localhost.localdomain> <1120848124.9303.135.camel@localhost.localdomain> Message-ID: <1120848303.9303.138.camel@localhost.localdomain> On Fri, 2005-07-08 at 13:42 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-08 at 20:02 +0300, Ville Skytt? wrote: > > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > > > perl-ExtUtils-XSBuilder: > > > Modules that parse C header files and create XS glue code > > > > Notes: > > - Missing "Requires: perl(Tie::IxHash)" - not a hard dep, but for the > > module to be fully useful. I don't think adding would cause problems. > > - noarch package -> no need for CFLAGS or OPTIMIZE in %build > > - No need to define perl_vendorarch or "|| :" after %check if you're > > targetting > FC2. > > - Installs executable *.pm and *.pod -> easyfix: > > "find . -type f | xargs chmod -x" in %prep > > - README contains copyright/licensing info, suggesting adding it. > > > > Go ahead and import to CVS and fix what you find worth fixing of the > > above, and I'll recheck. > > Made all the changes requested, except I left perl_vendorlib defined. I > wasn't sure if you meant that instead of perl_vendorarch or not. Never mind. I made that change too. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 8 18:47:03 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 13:47:03 -0500 Subject: Review: perl-Tie-DBI In-Reply-To: <1120842730.2892.39.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120842730.2892.39.camel@localhost.localdomain> Message-ID: <1120848423.9303.141.camel@localhost.localdomain> On Fri, 2005-07-08 at 20:12 +0300, Ville Skytt? wrote: > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > perl-Tie-DBI: > > Tie hashes to DBI relational databases > Go ahead and import to CVS and fix what you find worth fixing of the > above, and I'll recheck. All changes made, checked into CVS. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From adrian at lisas.de Fri Jul 8 18:49:47 2005 From: adrian at lisas.de (Adrian Reber) Date: Fri, 8 Jul 2005 20:49:47 +0200 Subject: Nexuiz, continued In-Reply-To: <20050708204349.683a9bf4@python2> References: <20050708161217.543f9291@python2> <20050708183216.GA24482@lisas.de> <20050708204349.683a9bf4@python2> Message-ID: <20050708184947.GA1582@lisas.de> On Fri, Jul 08, 2005 at 08:43:49PM +0200, Matthias Saou wrote: > Aha! I've been fighting with the icon too for the last 1/2h, thanks for > the fix! :-) I see still two problems : > - The explicit library name requirements, which break on x86_64 > - It's slow (unplayable!) on my AMD64 2800+ w/ Radeon 9200 even in 320x240 > > The first is a quick fix, but the second... ppracer, neverball etc. work > great, I would have thought that from the requirements listed in the > Readme my machine would have been sufficiently powerful :-( I can play it on my T31 with this card (1024x768): VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] It is not really fast but I get about 19fps with most of the details disabled. Adrian -- Adrian Reber http://lisas.de/~adrian/ system consumed all the paper for paging From jamatos at fc.up.pt Fri Jul 8 18:55:53 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 08 Jul 2005 19:55:53 +0100 Subject: Request for review: pytz and python-dateutil References: <42CAF271.50401@cora.nwra.com> <42CBF927.9010305@cora.nwra.com> Message-ID: Orion Poplawski wrote: > Yeah, matplotlib is one big mess of a bunch of packages smashed > together. At least with pytz and datetutil though, setup.py detects > their presence and does not install if present. This was actually > causing me grief when I tried to rebuild my python-matplotlib rpm with a > version already installed. This is what motivated me to explicitly > require pytz and python-dateutil - to obtain reproducible builds. I had the same problem before. :-) I think also that those packages are a good starting point to disentangle matplotlib knots. ;-) The important think is that the developers are aware of this issue and they intend to fix. Not immediately but there is no hurry. :-) > agg, pyparsing, and pycxx are more tightly integrated, install in the > matplotlib directory, and are referred to like: > > from matplotlib.pyparsing import Literal, Word, OneOrMore, ZeroOrMore, \ > Combine, Group, Optional, Forward, NotAny, alphas, nums, alphanums, > \ StringStart, StringEnd, ParseException > > (i.e. in the matplotlib namespace). Usually if the live in an independent namespace then it is easy to fix the dependency. I did not look to the code in question so take my this as my personal opinion. :-) > I personally am not interested in doing the work of splitting matplotlib > up, though I think the upstream project should do so. All this bundling > is just a PITA in my opinion. They had their reasons and I respect them. I remember the versions when they introduced dateutils and pytz dependencies. Time to search for them, to package and so on. If I was a user searching for a plot package I would forget and pass to the next candidate. For some of the packages sometimes the API changes even without changing the version. So unless you know and you are ready to deal with all the changes it becomes difficult to take this without lots of code (therefore with more bugs). It is always a tradeoff and sometimes there isn't an easy answer. Now remember also that matplotlib supports several toolkits and several platforms, it becomes really difficult to deal with the complexity associated with its dependency. After the last messages to the list the developers are now aware of the problems and they wish to fix it. That is good and I am happy that talking it is possible to solve most of the issues that we as packagers face. :-) > There is similar issues with basemap, a matplotlib toolkit that I want > to package. It bundles a version of PROJ.4. The maintainer though > warned me against using an external PROJ.4 library. Again, it installs > in its own space, so I don't have a big issue with it, but it strikes me > as against the whole point of having common libraries. Let us place this problems upstream and wait for an answer. The developers are friendly and very helpful. > Other opinions on this welcomed, and I'm happy to go with whatever > consensus develops. > > - Orion PS: Notice that matplotlib 0.83 was released today. :-) -- Jos? Ab?lio From tcallawa at redhat.com Fri Jul 8 20:43:00 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 15:43:00 -0500 Subject: Request for review: perl-Maypole (and friends) In-Reply-To: <1120843084.2892.46.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120843084.2892.46.camel@localhost.localdomain> Message-ID: <1120855380.22400.17.camel@localhost.localdomain> On Fri, 2005-07-08 at 20:18 +0300, Ville Skytt? wrote: > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > So, I am requesting review for perl-Maypole, and the 39 other packages > > that it needed as dependencies. Now, before everyone freaks and runs the > > other direction, the vast majority of these packages are perl noarch, > > straight off the template. > > Most of the packages seem to have some _cosmetic_ issues, so I think > it'll suffice to mention them once here, and not repeat in all reviews: > > - CFLAGS and OPTIMIZE not needed for noarch > - No need to define perl_vendor* or use "|| :" in %check in > FC2 > - LD_RUN_PATH hacks in %build not needed in > FC1 > > No need to rush and fix these now if you're not bored :). That can be > done after someone approves the packages. I got bored. ;) All cosmetic issues noted are fixed, new specs and SRPMS are at http://auroralinux.org/people/spot/review/Maypole 36 packages left. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From joelwreed at comcast.net Fri Jul 8 20:47:32 2005 From: joelwreed at comcast.net (joel reed) Date: Fri, 8 Jul 2005 16:47:32 -0400 Subject: Request for review: libxslt-plugin-regexp and libxslt-plugin-dates-and-times In-Reply-To: <20050708184140.E57287496E@hormel.redhat.com> References: <20050708184140.E57287496E@hormel.redhat.com> Message-ID: <20050708204731.GA13966@comcast.net> On Fri, Jul 08, 2005 at 02:41:40PM -0400, fedora-extras-list-request at redhat.com wrote: > From: Ignacio Vazquez-Abrams > Subject: Re: Request for review: libxslt-plugin-regexp and > libxslt-plugin-dates-and-times > To: Discussion related to Fedora Extras > > > On Fri, 2005-07-08 at 13:20 -0400, joel reed wrote: > > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec > > - Versions in Requires, BuildRequires, and %description need to be fixed > up > - Either add "Requires(post): /sbin/ldconfig > \nRequires(postun): /sbin/ldconfig" or change the %post[un] lines to > "%... -p /sbin/ldconfig" thank you for the feedback. i think this part: %post /sbin/ldconfig %postun /sbin/ldconfig can actually be deleted. then i don't need Requires(post) and Requires(postun) suggestions, right? i think they can be deleted because these plugin .so files are loaded dynamically be libxslt from "/usr/lib/libxslt/1.1/". my machine has: (%:~/src/libxslt-plugin-regexp-0.5) ls -1 /usr/lib/libxslt/1.1/ exslt_org_dates_and_times.la exslt_org_dates_and_times.so exslt_org_regular_expressions.la exslt_org_regular_expressions.so jr From ivazquez at ivazquez.net Fri Jul 8 22:13:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 08 Jul 2005 18:13:14 -0400 Subject: Request for review: libxslt-plugin-regexp and libxslt-plugin-dates-and-times In-Reply-To: <20050708204731.GA13966@comcast.net> References: <20050708184140.E57287496E@hormel.redhat.com> <20050708204731.GA13966@comcast.net> Message-ID: <1120860794.9522.37.camel@ignacio.ignacio.lan> On Fri, 2005-07-08 at 16:47 -0400, joel reed wrote: > On Fri, Jul 08, 2005 at 02:41:40PM -0400, fedora-extras-list-request at redhat.com wrote: > > From: Ignacio Vazquez-Abrams > > Subject: Re: Request for review: libxslt-plugin-regexp and > > libxslt-plugin-dates-and-times > > To: Discussion related to Fedora Extras > > > > > > On Fri, 2005-07-08 at 13:20 -0400, joel reed wrote: > > > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec > > > > - Versions in Requires, BuildRequires, and %description need to be fixed > > up > > - Either add "Requires(post): /sbin/ldconfig > > \nRequires(postun): /sbin/ldconfig" or change the %post[un] lines to > > "%... -p /sbin/ldconfig" > > thank you for the feedback. > > i think this part: > > %post > /sbin/ldconfig > > %postun > /sbin/ldconfig > > can actually be deleted. then i don't need Requires(post) and Requires(postun) > suggestions, right? i think they can be deleted because these plugin .so files > are loaded dynamically be libxslt from "/usr/lib/libxslt/1.1/". Fair enough. > my machine has: > > (%:~/src/libxslt-plugin-regexp-0.5) ls -1 /usr/lib/libxslt/1.1/ > exslt_org_dates_and_times.la > exslt_org_dates_and_times.so > exslt_org_regular_expressions.la > exslt_org_regular_expressions.so I think you can ditch the .la files. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jspaleta at gmail.com Fri Jul 8 23:16:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 8 Jul 2005 19:16:12 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507081332.58353.ermeyers@adelphia.net> References: <200507081332.58353.ermeyers@adelphia.net> Message-ID: <604aa7910507081616458416b5@mail.gmail.com> On 7/8/05, Eric R. Meyers wrote: > This comps.xml based list of groups might take a chunk out of the large number > of unassigned packages. But the trick is... who is going to take the time to keep the comps.xml file editted? Or have you thought of a way to incorporate a scripted action into the cvs environment so that individual mainainters can add/remove their packages to a defined group in a semi-automatic way? Something like: make groupadd "Games" make groupremove "office" from inside the local checkout of the cvs tree for a package -jef From wart at kobold.org Fri Jul 8 23:31:48 2005 From: wart at kobold.org (Michael Thomas) Date: Fri, 08 Jul 2005 16:31:48 -0700 Subject: Nexuiz, continued In-Reply-To: <20050708161217.543f9291@python2> References: <20050708161217.543f9291@python2> Message-ID: <42CF0CE4.6030507@kobold.org> Matthias Saou wrote: > Hi, > > What I feared happened : I ended up with and unrecognizable nexuiz.spec > file after starting making changes to Adian's spec :-/ > > Since the last email I sent earlier today, the major changes are : > - Update to 1.1. > - Split the program and the data into two separate packages. > - Use the correct icons, with multi-resolution ico -> png trick. > > You can find the files here : > http://ftp.es6.freshrpms.net/tmp/extras/ Minor nit: The build root for both specs should be: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) --Mike From mfleming at enlartenment.com Sat Jul 9 00:38:48 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 9 Jul 2005 10:38:48 +1000 Subject: Request for review / approval: mod_security. In-Reply-To: <42CE8B91.5010800@linux-kernel.at> References: <20050708235618.5416729e.mfleming@enlartenment.com> <42CE8B91.5010800@linux-kernel.at> Message-ID: <20050709103848.6b0eb994.mfleming@enlartenment.com> On Fri, 08 Jul 2005 16:20:01 +0200. Oliver Falk waffled thusly: > Hi Michael! > > On 07/08/2005 03:56 PM, Michael Fleming wrote: > > Hi folks, > > > > I've undoubtedly put this one up before a while back, but I've made a > > couple of small changes and added some useful rules in the default > > config. > > > > Therefore I'm putting this up for further review and approval (I don't > > recall seeing much last time - I felt such a package would generate more > > interest :-)). > > SRPM: > > http://www.enlartenment.com/extras/mod_security/mod_security-1.8.7-2.src.rpm > > > > Please have a look and feel free to send feedback or improvements. > > You don't need an approval if the package was allready approved and is > in cvs... Spec looks OK for me and and it seems you havn't change very > much... I've also been running it locally for quite a while so it does work as advertised :-D > But OK, I'd like to mention a few things: > - BuildRoot, as described in the PackagingGuidelines, pls. > (http://fedoraproject.org/wiki/PackagingGuidelines). > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) D'oh! Fixed :-) > - Why does the new package not depend on http(/-devel) >= 2.0.38, as > the old package in CVS does? I'm a little torn on this one - httpd-devel is indeed needed (and is listed in the BR unless my brain has completely gone to mush) but the explicit version I could probably drop. There are some packages out there that are actually httpd 1.3.x branch (for old-schoolers who just don't want to upgrade to Apache 2 yet. Each to their own I guess) and the version check would stop attempts to use it resulting in their Apache 1.3 install blowing up on them. On the other hand if they're particular enough to downgrade it they can pay attention to the version this package is actually intended for. > - Don't forget the %{dist} tag in the release, if you intend to cvs > commit this. Fixed. (%{?dist}) > > - setup can be written as setup -q (the -n modsecurity-%{version} is > not needed) Unfortunately the upstream developer has recently been using modsecurity (as opposed to mod_security) in the tarball and directory structure, thus it's use (I'd prefer to maintain the standard mod_ naming convention used by Apache modules). It's not given me any trouble even if it looks a bit out- of-place. > Best, > Oliver Updated SRPM http://www.enlartenment.com/extras/mod_security/mod_security-1.8.7-3.src.rpm I do have a CVS branch in -devel for this, I'll ensure it's synced so I don't confuse myself and others :-) (I'd requested review before but never got formal build approval) Cheers, Michael -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From wart at kobold.org Sat Jul 9 03:04:25 2005 From: wart at kobold.org (Wart) Date: Fri, 08 Jul 2005 20:04:25 -0700 Subject: Nexuiz, continued In-Reply-To: <42CF0CE4.6030507@kobold.org> References: <20050708161217.543f9291@python2> <42CF0CE4.6030507@kobold.org> Message-ID: <42CF3EB9.2020106@kobold.org> Michael Thomas wrote: > Matthias Saou wrote: > >> Hi, >> >> What I feared happened : I ended up with and unrecognizable nexuiz.spec >> file after starting making changes to Adian's spec :-/ >> >> Since the last email I sent earlier today, the major changes are : >> - Update to 1.1. >> - Split the program and the data into two separate packages. >> - Use the correct icons, with multi-resolution ico -> png trick. >> >> You can find the files here : >> http://ftp.es6.freshrpms.net/tmp/extras/ > > > Minor nit: The build root for both specs should be: > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) I can't seem to get this to build in mock. When I run a i386 build, I get an error about missing libX11. It seems that the Makefile uses 'uname -m' to determine where libX11 is located, which resolves to -L/usr/X11R6/lib64 on my x86_64 system. This is probably not a major problem, as it will only happen when trying to run i386 builds on x86_64. However, even when I run a x86_64 build on x86_64, I get the following errors: make[2]: Leaving directory `/builddir/build/BUILD/nexuiz-1.1' make[1]: Leaving directory `/builddir/build/BUILD/nexuiz-1.1' snd_main.o(.text+0xea): In function `S_Shutdown': /builddir/build/BUILD/nexuiz-1.1/snd_main.c:152: undefined reference to `_Mem_Free' ...as well as many more related to missing _Mem_Free, _Mem_FreePool, _Mem_Alloc, and related. --Mike From skvidal at phy.duke.edu Sat Jul 9 05:04:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 09 Jul 2005 01:04:49 -0400 Subject: Nexuiz, continued In-Reply-To: <42CF3EB9.2020106@kobold.org> References: <20050708161217.543f9291@python2> <42CF0CE4.6030507@kobold.org> <42CF3EB9.2020106@kobold.org> Message-ID: <1120885489.22153.2.camel@cutter> > I can't seem to get this to build in mock. > > When I run a i386 build, I get an error about missing libX11. It seems > that the Makefile uses 'uname -m' to determine where libX11 is located, > which resolves to -L/usr/X11R6/lib64 on my x86_64 system. This is > probably not a major problem, as it will only happen when trying to run > i386 builds on x86_64. > When you try to run mock to build i386 on an x86_64 before you run it run this command: setarch i686 bash then run your mock commands for i386 as normal. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Jul 9 06:30:40 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 9 Jul 2005 08:30:40 +0200 Subject: Nexuiz, continued In-Reply-To: <42CF0CE4.6030507@kobold.org> References: <20050708161217.543f9291@python2> <42CF0CE4.6030507@kobold.org> Message-ID: <20050709083040.4772965c@python2> Michael Thomas wrote : > Minor nit: The build root for both specs should be: > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) "preferred value" I personally never liked that id execution, and have always left it out. It makes no sense when ~/.rpmmacros is properly configured for "individual usage", and even less when using mach or mock. But it's just a matter of taste, really. Still, why BuildRoot still needs to be set in each and every spec and hasn't gotten a sane default years ago is beyond me. Seems silly to repeat the same each time. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.26 0.31 0.19 From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 9 08:25:01 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 09 Jul 2005 10:25:01 +0200 Subject: Request for review: gif2png Message-ID: <87k6k0l736.fsf@kosh.bigo.ensc.de> The gif2png program converts files from the obsolescent Graphic Interchange Format to Portable Network Graphics. The conversion preserves all graphic information, including transparency, perfectly. The gif2png program can even recover data from corrupted GIFs. The distribution also includes a Python script, web2png, that will convert entire web hierarchies (images and HTML or PHP pages). http://www.catb.org/~esr/gif2png/ http://ensc.de/fedora/gif2png.spec http://ensc.de/fedora/gif2png-2.5.1-1.src.rpm Thx Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From oliver at linux-kernel.at Sat Jul 9 09:06:54 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 9 Jul 2005 11:06:54 +0200 Subject: Request for review / approval: mod_security. In-Reply-To: <20050709103848.6b0eb994.mfleming@enlartenment.com> Message-ID: <200507090906.j6996VQ9032145@mail.linux-kernel.at> Michael Fleming wrote: > On Fri, 08 Jul 2005 16:20:01 +0200. Oliver Falk waffled thusly: [ ... ] > > On 07/08/2005 03:56 PM, Michael Fleming wrote: > > > Hi folks, > > > > > > I've undoubtedly put this one up before a while back, but > I've made > > > a couple of small changes and added some useful rules in > the default > > > config. > > > > > > Therefore I'm putting this up for further review and approval (I > > > don't recall seeing much last time - I felt such a package would > > > generate more interest :-)). > > > > > > SRPM: > > > > http://www.enlartenment.com/extras/mod_security/mod_security-1.8.7-2 > > > .src.rpm > > > > > > Please have a look and feel free to send feedback or improvements. > > > > You don't need an approval if the package was allready > > approved and is > > in cvs... Spec looks OK for me and and it seems you havn't > > change very much... > > I've also been running it locally for quite a while so it > does work as advertised :-D Fine. > > But OK, I'd like to mention a few things: > > - BuildRoot, as described in the PackagingGuidelines, pls. > > (http://fedoraproject.org/wiki/PackagingGuidelines). > > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > D'oh! Fixed :-) Good. > > - Why does the new package not depend on http(/-devel) >= > > 2.0.38, as the old package in CVS does? > > I'm a little torn on this one - httpd-devel is indeed needed > (and is listed in the BR unless my brain has completely gone > to mush) but the explicit version I could probably drop. > > There are some packages out there that are actually httpd > 1.3.x branch (for old-schoolers who just don't want to > upgrade to Apache 2 yet. Each to their own I guess) and the > version check would stop attempts to use it resulting in > their Apache 1.3 install blowing up on them. But old apaches, are called apache (do provide webserver, but not 'httpd' and not 'httpd-devel') and your package will not work this way... Believe me, I'm running 1.3 apache installs. :-) So for compatibility reasons, it's useless. Also FC/FE doesn't have apache 1.3.x packages... > On the other hand if they're particular enough to downgrade > it they can pay attention to the version this package is > actually intended for. However, if you like to drop the explicit version dependency, that's OK. > > - Don't forget the %{dist} tag in the release, if you > > intend to cvs commit this. > > Fixed. (%{?dist}) > > > > > - setup can be written as setup -q (the -n > > modsecurity-%{version} is > > not needed) > > Unfortunately the upstream developer has recently been using > modsecurity (as opposed to mod_security) in the tarball and > directory structure, thus it's use (I'd prefer to maintain > the standard mod_ naming convention used by Apache > modules). It's not given me any trouble even if it looks a > bit out- of-place. OK, if there was the need to do so, then it makes sense, let it as it is. > > Best, > > Oliver > > Updated SRPM > http://www.enlartenment.com/extras/mod_security/mod_security-1 > .8.7-3.src.rpm > > I do have a CVS branch in -devel for this, I'll ensure it's > synced so I don't confuse myself and others :-) (I'd > requested review before but never got formal build approval) There's no need for a 'build approval', you only need a cvs import approval, after the package is in CVS, you can - more or less - do what you want... :-) Please don't forget to request CVSSync if you intend to build the package for other branches as well (others than the 'devel'): http://fedoraproject.org/wiki/Extras/CVSSyncNeeded And if you havn't done yet, also request a bugzilla entry: http://fedoraproject.org/wiki/Extras/BugzillaAdmin >From my point, you've got the approval to import the new spec and request build! Even if this approval is not needed.... Best, Oliver From mfleming at enlartenment.com Sat Jul 9 09:48:00 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 9 Jul 2005 19:48:00 +1000 Subject: Request for review / approval: mod_security. In-Reply-To: <200507090906.j6996VQ9032145@mail.linux-kernel.at> References: <20050709103848.6b0eb994.mfleming@enlartenment.com> <200507090906.j6996VQ9032145@mail.linux-kernel.at> Message-ID: <20050709194800.77f61855.mfleming@enlartenment.com> On Sat, 9 Jul 2005 11:06:54 +0200. Oliver Falk waffled thusly: > Michael Fleming wrote: > > On Fri, 08 Jul 2005 16:20:01 +0200. Oliver Falk waffled thusly: > [ ... ] > > > On 07/08/2005 03:56 PM, Michael Fleming wrote: > > > > Hi folks, < mod_security needs approval :-) > > > > - Why does the new package not depend on http(/-devel) >= > > > 2.0.38, as the old package in CVS does? > > > > I'm a little torn on this one - httpd-devel is indeed needed > > (and is listed in the BR unless my brain has completely gone > > to mush) but the explicit version I could probably drop. > > > > There are some packages out there that are actually httpd > > 1.3.x branch (for old-schoolers who just don't want to > > upgrade to Apache 2 yet. Each to their own I guess) and the > > version check would stop attempts to use it resulting in > > their Apache 1.3 install blowing up on them. > > But old apaches, are called apache (do provide webserver, but not 'httpd' > and not 'httpd-devel') and your package will not work this way... Believe > me, I'm running 1.3 apache installs. :-) So for compatibility reasons, > it's useless. Also FC/FE doesn't have apache 1.3.x packages... True. I'm thinking of potential third-party packagers who do (yeah, I've seen at least one case of a "httpd-1.3.x" out there..), and whose repos users might mix FE with (I've also seen a couple of instances of users trying a "one with everything" yum.repos.d setup - can we have a "train wreck" waiting to happen folks?) OTOH they can learn from the experience, if they get it to install anyway :-) > > On the other hand if they're particular enough to downgrade > > it they can pay attention to the version this package is > > actually intended for. > > However, if you like to drop the explicit version dependency, that's OK. I've already done this :-) > > > Best, > > > Oliver > > > > Updated SRPM > > http://www.enlartenment.com/extras/mod_security/mod_security-1 > > .8.7-3.src.rpm > > > > I do have a CVS branch in -devel for this, I'll ensure it's > > synced so I don't confuse myself and others :-) (I'd > > requested review before but never got formal build approval) > > There's no need for a 'build approval', you only need a cvs import > approval, after the package is in CVS, you can - more or less - do what > you want... :-) I don't ever recall seeing or sending an APPROVED message for this one - if the spec and build are OK can we arrange one, just to ensure all the i's crossed and t's dotted? ;-) > Please don't forget to request CVSSync if you intend to build the package > for other branches as well (others than the 'devel'): > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded Will do (would like to get FC3 / FC4 branches once a devel branch install succeeds ) > And if you havn't done yet, also request a bugzilla entry: > http://fedoraproject.org/wiki/Extras/BugzillaAdmin Again, will do. I've no doubt some folks will want some extra default rule changes at some stage :-) > >From my point, you've got the approval to import the new spec and request > build! Even if this approval is not needed.... Already done (the exisiting version was a bit lacking, this one syncs with what you've reviewed.) > Best, > Oliver Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From ermeyers at adelphia.net Sat Jul 9 10:19:08 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Sat, 9 Jul 2005 06:19:08 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507081616458416b5@mail.gmail.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> Message-ID: <200507090619.24545.ermeyers@adelphia.net> On Friday 08 July 2005 19:16, Jeff Spaleta wrote: > On 7/8/05, Eric R. Meyers wrote: > > This comps.xml based list of groups might take a chunk out of the large > > number of unassigned packages. > > But the trick is... who is going to take the time to keep the > comps.xml file editted? > Or have you thought of a way to incorporate a scripted action into the > cvs environment so that individual mainainters can add/remove their > packages to a defined group in a semi-automatic way? > Something like: > make groupadd "Games" > make groupremove "office" > > from inside the local checkout of the cvs tree for a package > > -jef Jeff, (and others) I don't know what the big answer is. The idea is that there are 1031 of 1251 packages in Fedora-Extras that are in __nogroup__. You may or may not be thinking too complicated, because of your bigger picture, CVS perspective. I'm not there, because I'm new to your group. Seth only suggested that I start by taking a look at comps.xml's list of groups, and he did not tell me what to do with it, or what to do. I know that if you add the group Desktops, then __nogroup__ will lose a few items. For example. Thanks for you response. -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- 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 Jul 9 10:26:11 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 09 Jul 2005 13:26:11 +0300 Subject: Request for review / approval: mod_security. In-Reply-To: <20050709194800.77f61855.mfleming@enlartenment.com> References: <20050709103848.6b0eb994.mfleming@enlartenment.com> <200507090906.j6996VQ9032145@mail.linux-kernel.at> <20050709194800.77f61855.mfleming@enlartenment.com> Message-ID: <1120904771.2892.65.camel@localhost.localdomain> On Sat, 2005-07-09 at 19:48 +1000, Michael Fleming wrote: > > > Updated SRPM > > > http://www.enlartenment.com/extras/mod_security/mod_security-1 > > > .8.7-3.src.rpm One minor thing you may be interested in: httpd-mmn (mmn = "module magic number" AFAIK) provides means to specify a compatible install time httpd dependency. See mod_* specfiles in Core. From foolish at fedoraforum.org Sat Jul 9 10:46:14 2005 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Sat, 09 Jul 2005 12:46:14 +0200 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507090619.24545.ermeyers@adelphia.net> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: <1120905975.2991.5.camel@localhost.localdomain> I was under the impression that groups are there to allow the user to easily install software that are used together (through groupinstall). Software groups such as XCFE or Gnome desktop makes sense. Grouping software based on type, such as "music players", does not IMO. A user would only want one music player. What is the purpose of groups and based on what do we group software? -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- 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 andreas at bawue.net Sat Jul 9 11:04:19 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 9 Jul 2005 13:04:19 +0200 (CEST) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507090619.24545.ermeyers@adelphia.net> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: On Sat, 9 Jul 2005, Eric R. Meyers wrote: > I don't know what the big answer is. The idea is that there are 1031 of 1251 > packages in Fedora-Extras that are in __nogroup__. This "problem" stems from the fact that repoview groups the packages according to the comps.xml data and does not take the Group tag from the specfile into account. Now, I do think repoview is at fault here. The comps.xml package is used to group the packages into logical choices for the initial installation. If I want to develop gnome applications on my system, I'll check "Gnome Software Development" and it will make sure I have a compiler, a linker, make, auto-tools and the most important gnome and gtk libraries. If I have a soundcard, I'll check Multimedia and get an audio player, a video player and a volume control panel. That works great. But now apply this to extras, where we do have more than one audio player as Sindre pointed out. Assuming that comps.xml is a good choice for grouping packages, as repoview does, works for core, but is failing for extras. It would be more sensible to fall back on the specfile Group tag and sort the packages into these groups. bye, andreas From ville.skytta at iki.fi Sat Jul 9 11:22:54 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 09 Jul 2005 14:22:54 +0300 Subject: Review: perl-ExtUtils-XSBuilder In-Reply-To: <1120848303.9303.138.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120842157.2892.34.camel@localhost.localdomain> <1120848124.9303.135.camel@localhost.localdomain> <1120848303.9303.138.camel@localhost.localdomain> Message-ID: <1120908174.2892.86.camel@localhost.localdomain> On Fri, 2005-07-08 at 13:45 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-08 at 13:42 -0500, Tom 'spot' Callaway wrote: > > > > Made all the changes requested, except I left perl_vendorlib defined. I > > wasn't sure if you meant that instead of perl_vendorarch or not. > > Never mind. I made that change too. Yep, I made a copy-pasto. Thanks. Approval for perl-Tie-DBI and perl-ExtUtils-XSBuilder sent, and I intend to review perl-Template-Toolkit today. From mfleming at enlartenment.com Sat Jul 9 11:27:06 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 9 Jul 2005 21:27:06 +1000 Subject: Request for review / approval: mod_security. In-Reply-To: <1120904771.2892.65.camel@localhost.localdomain> References: <20050709103848.6b0eb994.mfleming@enlartenment.com> <200507090906.j6996VQ9032145@mail.linux-kernel.at> <20050709194800.77f61855.mfleming@enlartenment.com> <1120904771.2892.65.camel@localhost.localdomain> Message-ID: <20050709212706.0e6bdb21.mfleming@enlartenment.com> On Sat, 09 Jul 2005 13:26:11 +0300. Ville Skytt? waffled thusly: > On Sat, 2005-07-09 at 19:48 +1000, Michael Fleming wrote: > > > > > Updated SRPM > > > > http://www.enlartenment.com/extras/mod_security/mod_security-1 > > > > .8.7-3.src.rpm > > One minor thing you may be interested in: httpd-mmn (mmn = "module magic > number" AFAIK) provides means to specify a compatible install time httpd > dependency. See mod_* specfiles in Core. Excellent idea - I've looked at the mod_perl spec in Core and it seems ideal for my purposes (and very easy to integrate too.) I've just kicked off a local mock build with this tip folded in, so I'll see the result shortly. Thanks for the tip Ville, it'll come in very handy in the future too (I'd like to have a shot at submitting mod_geoip and dependencies too at some point) Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From adrian at lisas.de Sat Jul 9 12:23:26 2005 From: adrian at lisas.de (Adrian Reber) Date: Sat, 9 Jul 2005 14:23:26 +0200 Subject: Nexuiz, continued In-Reply-To: <20050708204349.683a9bf4@python2> References: <20050708161217.543f9291@python2> <20050708183216.GA24482@lisas.de> <20050708204349.683a9bf4@python2> Message-ID: <20050709122326.GA21034@lisas.de> On Fri, Jul 08, 2005 at 08:43:49PM +0200, Matthias Saou wrote: > Aha! I've been fighting with the icon too for the last 1/2h, thanks for > the fix! :-) I see still two problems : > - The explicit library name requirements, which break on x86_64 > - It's slow (unplayable!) on my AMD64 2800+ w/ Radeon 9200 even in 320x240 > > The first is a quick fix, but the second... ppracer, neverball etc. work > great, I would have thought that from the requirements listed in the > Readme my machine would have been sufficiently powerful :-( > > Other than that, you can consider the packages reviewed and approved! It is now imported into CVS. Adrian -- Adrian Reber http://lisas.de/~adrian/ * * * * * THIS TERMINAL IS IN USE * * * * * From dwmw2 at infradead.org Sat Jul 9 12:32:20 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 09 Jul 2005 13:32:20 +0100 Subject: Trademarks In-Reply-To: <14978.192.54.193.35.1120650107.squirrel@rousalka.dyndns.org> References: <1120303368.26373.30.camel@localhost.localdomain> <1120493791.19467.79.camel@hades.cambridge.redhat.com> <1120497799.18966.24.camel@cutter> <14978.192.54.193.35.1120650107.squirrel@rousalka.dyndns.org> Message-ID: <1120912340.23706.38.camel@baythorne.infradead.org> On Wed, 2005-07-06 at 13:41 +0200, Nicolas Mailhot wrote: > >> > Ville Skytt?? wrote: > >> > > Summary: Supplemental kernel modules for ThinkPad?? laptop > This is why aggressively adding UTF-8 symbols in specfiles is good : > it clarifies any false assumptions people may have about their > encoding. > > -1 for (R), (C) and other ascii-isms Incidentally, you've also shown an example of why it's good to aggressively use UTF-8 symbols in email. Your mail was claiming to be iso8859-1, but actually contained UTF-8. Was that a Fedora version of SquirrelMail you're using? Can you file a bug? -- dwmw2 From fredrik at dolda2000.com Sat Jul 9 12:51:43 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Sat, 09 Jul 2005 14:51:43 +0200 Subject: Request for review: icmpdn In-Reply-To: <42CE24BC.6060603@linux-kernel.at> References: <1120682668.14996.40.camel@pc7.dolda2000.com> <42CCD828.4090609@linux-kernel.at> <1120736408.14996.48.camel@pc7.dolda2000.com> <42CD15B6.1010304@linux-kernel.at> <1120765283.14996.57.camel@pc7.dolda2000.com> <42CE24BC.6060603@linux-kernel.at> Message-ID: <1120913504.14996.68.camel@pc7.dolda2000.com> On Fri, 2005-07-08 at 09:01 +0200, Oliver Falk wrote: > On 07/07/2005 09:41 PM, Fredrik Tolf wrote: > > Same links as before, but I can repeat them for the sake of > > completeness: > > > > > > > > I hope you find this OK. > > Approval sent out. Thank you! I still don't have my CVS account, though, so will anyone be as kind as to CVS sponsor this for the moment? Fredrik Tolf From andreas at bawue.net Sat Jul 9 13:00:52 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 9 Jul 2005 15:00:52 +0200 (CEST) Subject: Review still needed for dd_rescue/ddrescue/dd_rhelp In-Reply-To: References: Message-ID: Hello, On Wed, 6 Jul 2005, Andreas Thienemann wrote: there is still a review (and/or approval) needed for the ddrescue/dd_rescue/dd_rhelp combo. > Just a short recap of the current situation: > There exist two fault tollerant dd solutions. One is named dd_rescue, the > other is named ddrescue. Both have their pros and cons. dd_rescue together > with dd_rhelp (a bash helper script) looks a bit more advanced then the > GNU ddrescue, but this is my personal opinion. > > Problem was that there is currently a ddrescue package in the > fedora-extras tree, which does package dd_rescue. This is a bit confusing, > as there are people who'd like ddrescue as well. > > My suggestion to solve this mess is to include three packages, ddrescue, > dd_rescue and dd_rhelp with correct epoch and conflict tags to fix the > naming mess. > > Could someone please review these packages? > > http://home.bawue.de/~ixs/dd_rescue/ > http://home.bawue.de/~ixs/dd_rhelp/ > http://home.bawue.de/~ixs/ddrescue/ thanks, andreas From mricon at gmail.com Sat Jul 9 13:20:46 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sat, 9 Jul 2005 09:20:46 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: On 09/07/05, Andreas Thienemann wrote: > Assuming that comps.xml is a good choice for grouping packages, as > repoview does, works for core, but is failing for extras. It would be more > sensible to fall back on the specfile Group tag and sort the packages into > these groups. Then we need groups that are sane. Have you looked at the officially sanctioned list of RPM groups? They are useless. Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From andreas at bawue.net Sat Jul 9 13:37:54 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 9 Jul 2005 15:37:54 +0200 (CEST) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: On Sat, 9 Jul 2005, Konstantin Ryabitsev wrote: > Then we need groups that are sane. Have you looked at the officially > sanctioned list of RPM groups? They are useless. I beg to differ. The Application Subgroups Archiving, Communications, Databases, Editors, Emulators, Engineering, File, Internet, Multimedia, Productivity, Publishing, System, Text should fit most purposes. Admittedly, the difference between Communications and Internet is small, and Internet could be fleshed out a bit but still, it's a good basis for grouping packages. And I consider it much better then __nogroup__. bye, andreas From jspaleta at gmail.com Sat Jul 9 13:47:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 09:47:23 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: <604aa79105070906473597b73b@mail.gmail.com> On 7/9/05, Andreas Thienemann wrote: > On Sat, 9 Jul 2005, Konstantin Ryabitsev wrote: > > > Then we need groups that are sane. Have you looked at the officially > > sanctioned list of RPM groups? They are useless. > I beg to differ. And I beg to differ with you. I doubt you'll find consensous agreement on this issue. The fact right now is no tool in core is using that tag for anything. s-c-packages uses comps, anaconda uses comps, yum uses comps. I see absolutely NO value in having repodata using the tag information, in a way that is inconsistent with the tools. We find a way to expose and managed the comps "components" > And I consider it much better then __nogroup__. And I say coming up with a way for people to manage the comps.xml as part of CVS operations is even better. If we are going to use comps.xml in extras then there needs to be a mechanism by which people can add and remove packages to pre-defined comps groups easily. I would go further and make a "small" group of people the nominal maintainer of comps.xml and they are tasked with managing the list of groups and handling requests for new group definitions. -jef From mricon at gmail.com Sat Jul 9 13:52:17 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sat, 9 Jul 2005 09:52:17 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: (correcting gmail's reply-to-poster-only stupidity) On 09/07/05, Andreas Thienemann wrote: > And I consider it much better then __nogroup__. It doesn't have to be. It's only a matter of inclusion into comps.xml. I think part of the new package submission process, in addition to "make bugzilla entry" should be "suggest group placements." It makes a whole lot of more sense to go with comps.xml groups and not the silly RPM groups, since comps.xml allows to carry a lot more descriptive information than Root/Branch, and allows packages to be members of more than one group (sunbird, for example, is all of the following: publishing, internet, communications, productivity, editors). -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From mricon at gmail.com Sat Jul 9 13:55:10 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sat, 9 Jul 2005 09:55:10 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507081332.58353.ermeyers@adelphia.net> References: <200507081332.58353.ermeyers@adelphia.net> Message-ID: On 08/07/05, Eric R. Meyers wrote: > Why does it say 22 groups, when only 20 groups are listed? It probably counts some of the helper groups I use during indexing. I'll check it out. Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From jspaleta at gmail.com Sat Jul 9 13:56:49 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 09:56:49 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1120905975.2991.5.camel@localhost.localdomain> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <1120905975.2991.5.camel@localhost.localdomain> Message-ID: <604aa79105070906563ffcad29@mail.gmail.com> On 7/9/05, Sindre Pedersen Bjordal wrote: > I was under the impression that groups are there to allow the user to > easily install software that are used together (through groupinstall). > Software groups such as XCFE or Gnome desktop makes sense. The groups can do more than that. Package definitions inside a group can have default,manadatory and optional settings. go back and look at things like the Editors group from Core. Those items aren't all directly related. yum --disablerepo=extras-development groupinfo "Editors" ... Group: Editors Required Groups: Base Optional Metapkgs: <----- Optional Emacs Default Packages: vim-enhanced Optional Packages <---- Optional joe vim-X11 If you groupinstall with yum you dont get the optional items. But the optional items show up in the ui for system-config-packages. I realize that s-c-p is a dead end... but my point is any tool that replaces s-c-p can have access to the same optional group members as before through interaction with yum. You can use groups to hold optional packages that a basic groupinstall doesn't drag in, and Core is already doing this. None of the end-user facing tools uses the GROUP tag in the rpm header for anything useful. All the tools that attempt to "group" items pull the grouping info from comps. If extras is going to have groupings it needs to be done via comps to make sure the tools users are using see exactly what repoview sees. -jef From kaboom at oobleck.net Sat Jul 9 13:54:10 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 9 Jul 2005 09:54:10 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: On Sat, 9 Jul 2005, Andreas Thienemann wrote: > But now apply this to extras, where we do have more than one audio player > as Sindre pointed out. > > Assuming that comps.xml is a good choice for grouping packages, as > repoview does, works for core, but is failing for extras. It would be more > sensible to fall back on the specfile Group tag and sort the packages into > these groups. specfile Groups are equally useless. Does "Amusements/Graphics" really sound like the group you'd install, or even look in, to find the world's best gui X clock to you?[1] But all the other categories available are an equally poor fit.... That's one reason usual sentiment is that specfile Groups needs to die.... I think something like comps.xml, but for extras, would be a better fit in terms of goals of having groups of stuff easily installable with yum groupinstall and similar. The catch is figuring out how to group though. Sometimes you can do it by function (games group would probably be popular) but sometimes function doesn't make much sense (we probably don't want a windowmanagers group, we want a group for E + all its little applets, for blackbox + all its little applets, etc) later, chris [1] Just to pick on a package I maintain - xdaliclock From jspaleta at gmail.com Sat Jul 9 14:00:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 10:00:53 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: <604aa79105070907004bdda2a6@mail.gmail.com> On 7/9/05, Konstantin Ryabitsev wrote: > It doesn't have to be. It's only a matter of inclusion into comps.xml. > I think part of the new package submission process, in addition to > "make bugzilla entry" should be "suggest group placements." As a regular cvs user I think you need 3 seperate operations 1)a make command that lets you pull down the most current list of defined group tags 2)a make command to add your package to a set of groups 3a make command to remove your package from a set of groups. In the meantime however... would a wikipage like what we are using for bugzilla entries be a start? A wiki page where maintainers can request group adds and removals. And a "small:" group of maintainers in charge of comps.xml can integrate or deny those requests? -jef From andreas at bawue.net Sat Jul 9 14:05:14 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 9 Jul 2005 16:05:14 +0200 (CEST) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: On Sat, 9 Jul 2005, Konstantin Ryabitsev wrote: > > And I consider it much better then __nogroup__. > It doesn't have to be. It's only a matter of inclusion into comps.xml. > I think part of the new package submission process, in addition to > "make bugzilla entry" should be "suggest group placements." Great. That fixes things for extras. But what if one uses repoview to catalog third party repositories? The possibility not to group by comps.xml catalog but by RPM group might be very appreciated. > It makes a whole lot of more sense to go with comps.xml groups and not > the silly RPM groups, since comps.xml allows to carry a lot more > descriptive information than Root/Branch, and allows packages to be > members of more than one group (sunbird, for example, is all of the > following: publishing, internet, communications, productivity, > editors). Nobody said that comps.xml support should be dropped. Neither did anyone say that comps.xml is inferior to RPM groups. The problem is, how to procceed when there is no comps.xml file or the packages in question are not mentioned in the xml. The current solution is to drop them into __nogroup__. A better idea would be to fallback onto RPM groups in order to have _some_ kind of grouping. Or better, make it configurable via a cmd-line switch. That way even people who should for some reason prefer the RPM grouping will be happy. bye, andreas From mricon at gmail.com Sat Jul 9 14:09:45 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sat, 9 Jul 2005 10:09:45 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa79105070907004bdda2a6@mail.gmail.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> Message-ID: On 09/07/05, Jeff Spaleta wrote: > As a regular cvs user I think you need 3 seperate operations > 1)a make command that lets you pull down the most current list of > defined group tags > 2)a make command to add your package to a set of groups > 3a make command to remove your package from a set of groups. > > > In the meantime however... would a wikipage like what we are using for > bugzilla entries be a start? A wiki page where maintainers can > request group adds and removals. And a "small:" group of maintainers > in charge of comps.xml can integrate or deny those requests? I think we should combine -- a wikipage to suggest new groups, mandatory group packages, group meta-dependencies, and to handle stuff like i18n translations. Plus cvs tags for assigning the package as "optional" into already defined groups. That could work reasonably well. Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From skvidal at phy.duke.edu Sat Jul 9 14:34:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 09 Jul 2005 10:34:36 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: <1120919677.22153.7.camel@cutter> On Sat, 2005-07-09 at 16:05 +0200, Andreas Thienemann wrote: > On Sat, 9 Jul 2005, Konstantin Ryabitsev wrote: > > > > And I consider it much better then __nogroup__. > > It doesn't have to be. It's only a matter of inclusion into comps.xml. > > I think part of the new package submission process, in addition to > > "make bugzilla entry" should be "suggest group placements." > Great. That fixes things for extras. > > But what if one uses repoview to catalog third party repositories? > The possibility not to group by comps.xml catalog but by RPM group might > be very appreciated. > > > It makes a whole lot of more sense to go with comps.xml groups and not > > the silly RPM groups, since comps.xml allows to carry a lot more > > descriptive information than Root/Branch, and allows packages to be > > members of more than one group (sunbird, for example, is all of the > > following: publishing, internet, communications, productivity, > > editors). > Nobody said that comps.xml support should be dropped. Neither did > anyone say that comps.xml is inferior to RPM groups. > The problem is, how to procceed when there is no comps.xml file or the > packages in question are not mentioned in the xml. > > The current solution is to drop them into __nogroup__. A better idea would > be to fallback onto RPM groups in order to have _some_ kind of grouping. > Right now if no comps.xml is found then repoview uses the rpm group tag to categorize the packages. It's done that for a while. -sv From buildsys at fedoraproject.org Sat Jul 9 15:28:39 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 9 Jul 2005 11:28:39 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050709152839.DF9DC83BE@extras64.linux.duke.edu> Packages built and released for Fedora Extras 3: 14 anjuta-1.2.3-1.fc3 bazaar-1.4.2-2.fc3 fedora-rpmdevtools-1.1-1.fc3 fyre-1.0.0-9.fc3 glabels-2.0.3-2.fc3 jhead-2.4-2.fc3 jhead-2.4-3.fc3 libifp-1.0.0.1-1.fc3 mgopen-fonts-0.20050515-1 most-4.10.2-1.fc3 perl-Tree-DAG_Node-1.05-2.fc3 screem-0.12.2-1 scribus-1.2.2.1-2.fc3 sylpheed-claws-1.0.5-1 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 Sat Jul 9 15:49:54 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 9 Jul 2005 11:49:54 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050709154954.DB8A283BE@extras64.linux.duke.edu> Packages built and released for Fedora Extras 4: 16 anjuta-1.2.3-1.fc4 bazaar-1.4.2-2.fc4 fedora-rpmdevtools-1.1-1.fc4 fyre-1.0.0-9.fc4 galeon-1.3.21-8.fc4 glabels-2.0.3-2.fc4 grip-3.2.0-5.fc4 jhead-2.4-2.fc4 jhead-2.4-3.fc4 libifp-1.0.0.1-1.fc4 liferea-0.9.3-1.fc4 mgopen-fonts-0.20050515-1 most-4.10.2-1.fc4 perl-Tree-DAG_Node-1.05-2.fc4 screem-0.14.1-1.fc4 scribus-1.2.2.1-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From katzj at redhat.com Sat Jul 9 15:56:07 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 09 Jul 2005 11:56:07 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: <1120924567.4128.4.camel@bree.local.net> On Sat, 2005-07-09 at 16:05 +0200, Andreas Thienemann wrote: > On Sat, 9 Jul 2005, Konstantin Ryabitsev wrote: > > > And I consider it much better then __nogroup__. > > It doesn't have to be. It's only a matter of inclusion into comps.xml. > > I think part of the new package submission process, in addition to > > "make bugzilla entry" should be "suggest group placements." > Great. That fixes things for extras. > > But what if one uses repoview to catalog third party repositories? > The possibility not to group by comps.xml catalog but by RPM group might > be very appreciated. Third party repositories are going to want to start providing a comps.xml as well. When the son of system-config-packages shows up with the ability to add additional repositories, people are going to want to have the categorization and the group tags are *not* the way to do it for a variety of reasons. Jeremy From jspaleta at gmail.com Sat Jul 9 16:47:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 12:47:23 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> Message-ID: <604aa79105070909474dd7212a@mail.gmail.com> On 7/9/05, Konstantin Ryabitsev wrote: > I think we should combine -- a wikipage to suggest new groups, > mandatory group packages, group meta-dependencies, and to handle stuff > like i18n translations. Plus cvs tags for assigning the package as > "optional" into already defined groups. > > That could work reasonably well. Are volunteering to help process the requests as they come into the wikipage? We could create a workflow example with the glabels package, where I act as the requestor and you act as the comps maintainer and hammer out some text for the Extras New Package Guide wikipage on how to go about requesting inclusion into the comps. I assure you, I can do an exceedingly good job at making boneheaded mistakes, so I'm the perfect test case for instruction drafting. -jef From mricon at gmail.com Sat Jul 9 17:01:15 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sat, 9 Jul 2005 13:01:15 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa79105070909474dd7212a@mail.gmail.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa79105070909474dd7212a@mail.gmail.com> Message-ID: On 09/07/05, Jeff Spaleta wrote: > Are volunteering to help process the requests as they come into the wikipage? Unfortunately, I cannot take on any new projects right now, since I'm about to go on an extended hiatus (probably several months long). I should eventually emerge from it, but at the moment I'm going to have to duck the suggestion. :) Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From jspaleta at gmail.com Sat Jul 9 17:05:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 13:05:50 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa79105070909474dd7212a@mail.gmail.com> Message-ID: <604aa791050709100562fa994a@mail.gmail.com> On 7/9/05, Konstantin Ryabitsev wrote: > Unfortunately, I cannot take on any new projects right now, since I'm > about to go on an extended hiatus (probably several months long). I > should eventually emerge from it, but at the moment I'm going to have > to duck the suggestion. :) That's sort of the catch... to use a wiki request page approach a "small" group of people need to act as comps file admins to process the requests. I'm willing to help out with this with writing up instructions in the wiki, and maybe even being one of the admins for the comps requests. But I don't have enough experience with mucking around with the comps files to be able to handle this out of the gate. I'd need some on the job training. So if you can't help get this ball rolling... is there anyone else out there in Extras land who can? Feel free to delibrately name people whom I should actively poke in the eye. -jef From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 9 17:19:49 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 09 Jul 2005 19:19:49 +0200 Subject: Request for review: kismet Message-ID: <87br5blwwa.fsf@kosh.bigo.ensc.de> Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and can sniff 802.11b, 802.11a, and 802.11g traffic. Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and infering the presence of nonbeaconing networks via data traffic. http://www.kismetwireless.net/ http://ensc.de/fedora/kismet.spec http://ensc.de/fedora/kismet-0.0.2005.06.R1-1.src.rpm Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From wart at kobold.org Sat Jul 9 17:25:07 2005 From: wart at kobold.org (Wart) Date: Sat, 09 Jul 2005 10:25:07 -0700 Subject: Nexuiz, continued In-Reply-To: <1120885489.22153.2.camel@cutter> References: <20050708161217.543f9291@python2> <42CF0CE4.6030507@kobold.org> <42CF3EB9.2020106@kobold.org> <1120885489.22153.2.camel@cutter> Message-ID: <42D00873.7080802@kobold.org> seth vidal wrote: >>I can't seem to get this to build in mock. >> >>When I run a i386 build, I get an error about missing libX11. It seems >>that the Makefile uses 'uname -m' to determine where libX11 is located, >>which resolves to -L/usr/X11R6/lib64 on my x86_64 system. This is >>probably not a major problem, as it will only happen when trying to run >>i386 builds on x86_64. >> > > > When you try to run mock to build i386 on an x86_64 before you run it > run this command: > setarch i686 bash > > then run your mock commands for i386 as normal. That fixed it. Thanks. --Mike From taylor at haleph.com Sat Jul 9 17:21:15 2005 From: taylor at haleph.com (Taylor Stearns) Date: Sat, 9 Jul 2005 13:21:15 -0400 Subject: New package: msmtp In-Reply-To: <20050622215328.GA9276@arctangent.net> References: <20050622215328.GA9276@arctangent.net> Message-ID: <20050709172115.GA28215@arctangent.net> On Wed 22, Taylor Stearns wrote: > Howdy, > > I've had some msmtp packages sitting around > for a while that Lee-Win Tai cleaned up and suggested submitting to > Extras. So here it is: > > * msmtp (GPL): > http://www.haleph.com/download/msmtp-1.4.1-2.src.rpm > > In the default mode, msmtp transmits a mail to an SMTP server (for example > at a free mail provider) which does the delivery. To use this program > with your mail user agent (MUA), create a configuration file with your > mail account(s) and tell your MUA to call msmtp instead of > /usr/sbin/sendmail. Ping. I hope somebody out there found this useful; I need CVS sponsorship to commit it, but I haven't heard any feedback regarding the package. A new version was released a few days ago which I updated the spec for: http://www.haleph.com/download/rpms/msmtp-1.4.2-1.src.rpm I would appreciate comments and/or criticism (or sponsorship). Thanks. -- Taylor Stearns taylor at haleph.com From wart at kobold.org Sat Jul 9 18:20:01 2005 From: wart at kobold.org (Wart) Date: Sat, 09 Jul 2005 11:20:01 -0700 Subject: Nexuiz, continued In-Reply-To: <42CF3EB9.2020106@kobold.org> References: <20050708161217.543f9291@python2> <42CF0CE4.6030507@kobold.org> <42CF3EB9.2020106@kobold.org> Message-ID: <42D01551.8060206@kobold.org> Wart wrote: > However, even when I run a x86_64 build on x86_64, I get the following > errors: > > make[2]: Leaving directory `/builddir/build/BUILD/nexuiz-1.1' > make[1]: Leaving directory `/builddir/build/BUILD/nexuiz-1.1' > snd_main.o(.text+0xea): In function `S_Shutdown': > /builddir/build/BUILD/nexuiz-1.1/snd_main.c:152: undefined reference to > `_Mem_Free' > > ...as well as many more related to missing _Mem_Free, _Mem_FreePool, > _Mem_Alloc, and related. This seems to be a smp issue. When I build with "%_smp_mflags -j1", it builds fine on my smp machine. But with "%_smp_mflags -j2", I get the above build error about half the time. It seems to come from 'zone.c' not being compiled before either nexuiz-glx or nexuiz-dedicated. You might want to remove %{?_smp_mflags} from the spec file until the makefile can be fixed. --Mike From ville.skytta at iki.fi Sat Jul 9 18:20:08 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 09 Jul 2005 21:20:08 +0300 Subject: Review: perl-Template-Toolkit In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <1120933208.2892.148.camel@localhost.localdomain> On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > perl-Template-Toolkit: > Template processing system I have had a package of this too for some time, so I merged it with yours, results attached. The changes should be mostly self explanatory, but here's a few comments about bits that I think could use a second look: - Like you noted, the GD tests are sort of old, fragile and broken by design, so I don't mind taking your approach and simply disabling it instead of tweaking. "Fix" included for reference anyway, because I had it around. - I had an install time dependency on tetex-dvips and tetex-latex, but I don't remember what app that was for. If they're not installed, some (not that often used, I think) parts of TT aren't functional. But since they're fairly large packages, I think it's acceptable to ask packages that specifically need that (optional per se) functionality from TT to pull them in. So I didn't include this bit in the patch. - The examples take some 50 kB in rpm size, and about 2 MB when installed. Dunno if worth excluding or if they should just be installed in %doc (like the "docs" dir in this patch), you decide. Feel free to commit to CVS and I'll recheck. -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Template-Toolkit-gdpngtest.patch Type: text/x-patch Size: 1218 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Template-Toolkit.spec.patch Type: text/x-patch Size: 3678 bytes Desc: not available URL: From ed at eh3.com Sat Jul 9 19:04:31 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 09 Jul 2005 15:04:31 -0400 Subject: Review Request: NCO and CDO In-Reply-To: <1114295776.18906.18.camel@localhost.localdomain> References: <1113839355.16955.273.camel@ernie> <1114180831.27414.140.camel@ernie> <1114269014.3297.167.camel@localhost.localdomain> <1114293644.17203.78.camel@ernie> <1114295776.18906.18.camel@localhost.localdomain> Message-ID: <1120935872.13579.93.camel@ernie> On Sat, 2005-04-23 at 17:36 -0500, Tom 'spot' Callaway wrote: > > I'll sponsor NCO and CDO (NCO is contingent on opendap's sponsorship, > due to BuildRequires). Hi Tom, The following patch for udunits.spec fixes the "shlib-with-non-pic- code /usr/lib/libnco-3.0.1.so" problem and it works-for-me on FC3 and FC4 for i386 machines: http://mitgcm.org/eh3/fedora_misc/udunits.spec.patch Please apply or, if its somehow botched, please let me know. thanks! Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From wart at kobold.org Sat Jul 9 19:07:27 2005 From: wart at kobold.org (Wart) Date: Sat, 09 Jul 2005 12:07:27 -0700 Subject: New package: msmtp In-Reply-To: <20050709172115.GA28215@arctangent.net> References: <20050622215328.GA9276@arctangent.net> <20050709172115.GA28215@arctangent.net> Message-ID: <42D0206F.8090401@kobold.org> Taylor Stearns wrote: > On Wed 22, Taylor Stearns wrote: > >>Howdy, >> >>I've had some msmtp packages sitting around >>for a while that Lee-Win Tai cleaned up and suggested submitting to >>Extras. So here it is: >> >>* msmtp (GPL): >>http://www.haleph.com/download/msmtp-1.4.1-2.src.rpm >> >>In the default mode, msmtp transmits a mail to an SMTP server (for example >>at a free mail provider) which does the delivery. To use this program >>with your mail user agent (MUA), create a configuration file with your >>mail account(s) and tell your MUA to call msmtp instead of >>/usr/sbin/sendmail. > > > Ping. I hope somebody out there found this useful; I need CVS > sponsorship to commit it, but I haven't heard any feedback regarding the > package. A new version was released a few days ago which I updated the > spec for: > http://www.haleph.com/download/rpms/msmtp-1.4.2-1.src.rpm > > I would appreciate comments and/or criticism (or sponsorship). Thanks. Good ---- * Clean output from rpmlint * Package and spec file named correctly * md5sum matches upstream sources * Seems to follow PackagingGuidelines * Acceptible GPL license * Legible spec file * No duplicate files * File permissions look ok Check ----- * Builds in mock for i386 and x86_64 One build warning on both platforms. You might want to check the upstream author to see if this is a problem: base64.c: In function 'isbase64': base64.c:284: warning: comparison is always true due to limited range of data type Bad --- Use %find_lang to handle the de locale instead of %{_prefix}/share/locale/... I didn't try running the program. --Mike From ville.skytta at iki.fi Sat Jul 9 19:12:34 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 09 Jul 2005 22:12:34 +0300 Subject: Request for review: perl-gettext Message-ID: <1120936354.2892.150.camel@localhost.localdomain> perl-gettext is an internationalization library for Perl. Should be a trivial review: http://cachalot.mine.nu/4/SRPMS/perl-gettext-1.05-0.2.src.rpm From Nicolas.Mailhot at laPoste.net Sat Jul 9 19:42:36 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 09 Jul 2005 21:42:36 +0200 Subject: Trademarks In-Reply-To: <1120912340.23706.38.camel@baythorne.infradead.org> References: <1120303368.26373.30.camel@localhost.localdomain> <1120493791.19467.79.camel@hades.cambridge.redhat.com> <1120497799.18966.24.camel@cutter> <14978.192.54.193.35.1120650107.squirrel@rousalka.dyndns.org> <1120912340.23706.38.camel@baythorne.infradead.org> Message-ID: <1120938157.19620.9.camel@rousalka.dyndns.org> Le samedi 09 juillet 2005 ? 13:32 +0100, David Woodhouse a ?crit : > On Wed, 2005-07-06 at 13:41 +0200, Nicolas Mailhot wrote: > > >> > Ville Skytt?? wrote: > > >> > > Summary: Supplemental kernel modules for ThinkPad?? laptop > > > This is why aggressively adding UTF-8 symbols in specfiles is good : > > it clarifies any false assumptions people may have about their > > encoding. > > > > -1 for (R), (C) and other ascii-isms > > Incidentally, you've also shown an example of why it's good to > aggressively use UTF-8 symbols in email. Your mail was claiming to be > iso8859-1, but actually contained UTF-8. > > Was that a Fedora version of SquirrelMail you're using? Can you file a > bug? Yep that's a FC version. But honestly I don't feel I have enough material to file a bug, or is writing "SquirrelMail messes up encodings" sufficient ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Sat Jul 9 19:43:26 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 09 Jul 2005 22:43:26 +0300 Subject: Request for review: perl-gettext In-Reply-To: <1120936354.2892.150.camel@localhost.localdomain> References: <1120936354.2892.150.camel@localhost.localdomain> Message-ID: <1120938206.2892.154.camel@localhost.localdomain> On Sat, 2005-07-09 at 22:12 +0300, Ville Skytt? wrote: > Should be a trivial review: > http://cachalot.mine.nu/4/SRPMS/perl-gettext-1.05-0.2.src.rpm Oops, on a second thought, I'll just enhance the app I need this for so it can use Locale::Messages (from perl-libintl, already in Extras) or Locale::gettext (from this package) depending on which one is available. So, submission withdrawn, no need for a review. From oliver at linux-kernel.at Sat Jul 9 21:19:06 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 9 Jul 2005 23:19:06 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120913504.14996.68.camel@pc7.dolda2000.com> Message-ID: <200507092118.j69LIfgo014313@mail.linux-kernel.at> > On Fri, 2005-07-08 at 09:01 +0200, Oliver Falk wrote: > > On 07/07/2005 09:41 PM, Fredrik Tolf wrote: > > > Same links as before, but I can repeat them for the sake of > > > completeness: > > > > > > > > > > > > I hope you find this OK. > > > > Approval sent out. > > Thank you! > > I still don't have my CVS account, though, so will anyone be > as kind as to CVS sponsor this for the moment? * Imported * Requested Bugzilla Entry for you * Requested CVSSync for FC3, FC4 * Requested initial build on devel branch I hope this is OK for you? Best, Oliver From oliver at linux-kernel.at Sat Jul 9 21:20:12 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 9 Jul 2005 23:20:12 +0200 Subject: Request for review / approval: mod_security. In-Reply-To: <20050709212706.0e6bdb21.mfleming@enlartenment.com> Message-ID: <200507092119.j69LJlrP014361@mail.linux-kernel.at> > On Sat, 09 Jul 2005 13:26:11 +0300. Ville Skytt? waffled thusly: > > > On Sat, 2005-07-09 at 19:48 +1000, Michael Fleming wrote: > > > > > > > Updated SRPM > > > > > http://www.enlartenment.com/extras/mod_security/mod_security-1 > > > > > .8.7-3.src.rpm > > > > One minor thing you may be interested in: httpd-mmn (mmn = "module > > magic number" AFAIK) provides means to specify a compatible install > > time httpd dependency. See mod_* specfiles in Core. > > Excellent idea - I've looked at the mod_perl spec in Core and > it seems ideal for my purposes (and very easy to integrate > too.) I've just kicked off a local mock build with this tip > folded in, so I'll see the result shortly. > > Thanks for the tip Ville, it'll come in very handy in the > future too (I'd like to have a shot at submitting mod_geoip > and dependencies too at some > point) Good idea, didn't think about this... Best, Oliver From adrian at lisas.de Sat Jul 9 22:05:38 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 10 Jul 2005 00:05:38 +0200 Subject: Request for review: gif2png In-Reply-To: <87k6k0l736.fsf@kosh.bigo.ensc.de> References: <87k6k0l736.fsf@kosh.bigo.ensc.de> Message-ID: <20050709220538.GA26870@lisas.de> On Sat, Jul 09, 2005 at 10:25:01AM +0200, Enrico Scholz wrote: > The gif2png program converts files from the obsolescent Graphic > Interchange Format to Portable Network Graphics. The conversion > preserves all graphic information, including transparency, > perfectly. The gif2png program can even recover data from corrupted > GIFs. > > The distribution also includes a Python script, web2png, that will > convert entire web hierarchies (images and HTML or PHP pages). > > http://ensc.de/fedora/gif2png.spec > http://ensc.de/fedora/gif2png-2.5.1-1.src.rpm + rpmlint doesn't complain + builds in mock + clean installation and removal + source verfied against upstream + spec looks good + works as expected APPROVED non-blockers: * libpng-devel already requires zlib-devel And I haven't seen this in other spec files yet: What is the difference between "%{version}" and "%version"? If there is any difference at all... Adrian From bugs.michael at gmx.net Sat Jul 9 23:19:47 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 10 Jul 2005 01:19:47 +0200 Subject: Request for review: gif2png In-Reply-To: <20050709220538.GA26870@lisas.de> References: <87k6k0l736.fsf@kosh.bigo.ensc.de> <20050709220538.GA26870@lisas.de> Message-ID: <20050710011947.1d28f23e.bugs.michael@gmx.net> On Sun, 10 Jul 2005 00:05:38 +0200, Adrian Reber wrote: > And I haven't seen this in other spec files yet: What is the difference > between "%{version}" and "%version"? If there is any difference at all... The braces help the parser and avoid ambiguities. Parse this: %{version}rc1 %versionrc1 Ooops! From fredrik at dolda2000.com Sun Jul 10 00:51:41 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Sun, 10 Jul 2005 02:51:41 +0200 Subject: Request for review: icmpdn In-Reply-To: <200507092118.j69LIfgo014313@mail.linux-kernel.at> References: <200507092118.j69LIfgo014313@mail.linux-kernel.at> Message-ID: <1120956701.29955.0.camel@pc7.dolda2000.com> On Sat, 2005-07-09 at 23:19 +0200, Oliver Falk wrote: > > On Fri, 2005-07-08 at 09:01 +0200, Oliver Falk wrote: > > > On 07/07/2005 09:41 PM, Fredrik Tolf wrote: > > > > Same links as before, but I can repeat them for the sake of > > > > completeness: > > > > > > > > > > > > > > > > I hope you find this OK. > > > > > > Approval sent out. > > > > Thank you! > > > > I still don't have my CVS account, though, so will anyone be > > as kind as to CVS sponsor this for the moment? > > * Imported > * Requested Bugzilla Entry for you > * Requested CVSSync for FC3, FC4 > * Requested initial build on devel branch > > I hope this is OK for you? Thank you very much! I guess that should be all that I had planned to do, but then again, I'm new to the Extras system. I'll have to read up on it on the Wiki once I get my account. Again, thanks for all your help! Fredrik Tolf From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 10 07:35:18 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 10 Jul 2005 09:35:18 +0200 Subject: Request for review: gif2png In-Reply-To: <20050709220538.GA26870@lisas.de> (Adrian Reber's message of "Sun, 10 Jul 2005 00:05:38 +0200") References: <87k6k0l736.fsf@kosh.bigo.ensc.de> <20050709220538.GA26870@lisas.de> Message-ID: <877jfzktah.fsf@kosh.bigo.ensc.de> adrian at lisas.de (Adrian Reber) writes: >> http://ensc.de/fedora/gif2png.spec >> http://ensc.de/fedora/gif2png-2.5.1-1.src.rpm > ... > APPROVED > > non-blockers: > * libpng-devel already requires zlib-devel ok, removed > And I haven't seen this in other spec files yet: What is the difference > between "%{version}" and "%version"? If there is any difference at > all... It is like '$foo' and '${foo}' in the shell; braces are avoiding ambiguities and allow additional tricks (e.g. '%{?') but are not needed for most cases. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From menno-fedora at freshfoo.com Sun Jul 10 10:44:25 2005 From: menno-fedora at freshfoo.com (Menno Smits) Date: Sun, 10 Jul 2005 20:44:25 +1000 Subject: Maintenance of python-docutils Message-ID: <42D0FC09.9010208@freshfoo.com> Hi all, I intend to take over maintenance of the python-docutils package from Toshio Kuratomi (toshio at tiki-lounge.com) starting today, until he has reliable internet access again. This has been approved by Toshio. My bugzilla account is: menno at freshfoo.com Could I please also have permission to update the wiki pages? Thanks, Menno From bugs.michael at gmx.net Sun Jul 10 11:39:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 10 Jul 2005 13:39:43 +0200 Subject: common tobuild,1.1888,1.1889 In-Reply-To: <200507101052.j6AAqDRA032552@cvs-int.fedora.redhat.com> References: <200507101052.j6AAqDRA032552@cvs-int.fedora.redhat.com> Message-ID: <20050710133943.5dd81e1e.bugs.michael@gmx.net> On Sun, 10 Jul 2005 06:52:13 -0400, Jean-Luc Fontaine wrote: > Author: jfontain > > Update of /cvs/extras/common > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv32535 > > Modified Files: > tobuild > Log Message: > request build of rpms/moomps/FC-3 moomps-5_2-1_fc3 for fc3 > > > Index: tobuild > =================================================================== > RCS file: /cvs/extras/common/tobuild,v > retrieving revision 1.1888 > retrieving revision 1.1889 > diff -u -r1.1888 -r1.1889 > --- tobuild 10 Jul 2005 07:48:19 -0000 1.1888 > +++ tobuild 10 Jul 2005 10:52:11 -0000 1.1889 > @@ -1,37 +1 @@ > -# this is the build control file. the format is > -# user repo tag target status > -# > -ertzing rpms/libevent/devel libevent-1_1a-2_fc5 devel > -jspaleta rpms/glabels/FC-3 glabels-2_0_3-2_fc3 fc3 > -ivazquez rpms/libifp/FC-3 libifp-1_0_0_1-1_fc3 fc3 > -ivazquez rpms/libifp/FC-4 libifp-1_0_0_1-1_fc4 fc4 > -ivazquez rpms/libifp/devel libifp-1_0_0_1-1_fc5 devel > -ivazquez rpms/fyre/FC-3 fyre-1_0_0-9_fc3 fc3 > -ivazquez rpms/fyre/FC-4 fyre-1_0_0-9_fc4 fc4 > -ivazquez rpms/fyre/devel fyre-1_0_0-9_fc5 devel > -scop rpms/fedora-rpmdevtools/FC-3 fedora-rpmdevtools-1_1-1_fc3 fc3 > -scop rpms/fedora-rpmdevtools/FC-4 fedora-rpmdevtools-1_1-1_fc4 fc4 > -scop rpms/fedora-rpmdevtools/devel fedora-rpmdevtools-1_1-1_fc5 devel > -adrian rpms/jhead/devel jhead-2_4-1_fc5 devel > -lmacken rpms/naim/devel naim-0_11_7_3_1-2_fc5 devel > -uwog rpms/aiksaurus/devel aiksaurus-1_2_1-9 devel > -adrian rpms/jhead/devel jhead-2_4-2_fc5 devel > -adrian rpms/jhead/FC-4 jhead-2_4-2_fc4 fc4 > -adrian rpms/jhead/FC-3 jhead-2_4-2_fc3 fc3 > -adrian rpms/jhead/FC-3 jhead-2_4-3_fc3 fc3 > -adrian rpms/jhead/FC-4 jhead-2_4-3_fc4 fc4 > -adrian rpms/jhead/devel jhead-2_4-3_fc5 devel > -petersen rpms/scim-anthy/FC-4 scim-anthy-0_5_1-1_fc4 fc4 > -petersen rpms/scim-anthy/FC-4 scim-anthy-0_5_1-2_fc4 fc4 > -petersen rpms/scim/devel scim-1_3_3-1_fc5 devel > -ensc rpms/ip-sentinel/FC-3 ip-sentinel-0_12-5_fc3 fc3 > -ixs rpms/barcode/devel barcode-0_98-6_fc5 devel > -ensc rpms/ip-sentinel/FC-4 ip-sentinel-0_12-5_fc4 fc4 > -ensc rpms/ip-sentinel/devel ip-sentinel-0_12-5_fc5 devel > -ixs rpms/mod_suphp/devel mod_suphp-0_5_2-8_fc5 devel > -ixs rpms/mod_suphp/FC-3 mod_suphp-0_5_2-8_fc3 fc3 > -ixs rpms/mod_suphp/FC-4 mod_suphp-0_5_2-8_fc4 fc4 > -oliver rpms/icmpdn/devel icmpdn-0_3-2 devel > -ensc rpms/gif2png/FC-3 gif2png-2_5_1-1_fc3 fc3 > -ensc rpms/gif2png/FC-4 gif2png-2_5_1-1_fc4 fc4 > -ensc rpms/gif2png/devel gif2png-2_5_1-1_fc5 devel > +jfontain rpms/moomps/FC-3 moomps-5_2-1_fc3 fc3 Since a very few people still have problems with "make build", please make sure you have the very latest "common" checkout. The issue here seems to be that the "cvs up -C tobuild" fails and then you commit changes to a non-existant tobuild file. Why the cvs up fails for you and the commit doesn't, would need to be investigated by somebody. From jfontain at free.fr Sun Jul 10 12:08:46 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 10 Jul 2005 14:08:46 +0200 Subject: common tobuild,1.1888,1.1889 In-Reply-To: <20050710133943.5dd81e1e.bugs.michael@gmx.net> References: <200507101052.j6AAqDRA032552@cvs-int.fedora.redhat.com> <20050710133943.5dd81e1e.bugs.michael@gmx.net> Message-ID: <42D10FCE.9090308@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Sun, 10 Jul 2005 06:52:13 -0400, Jean-Luc Fontaine wrote: > >> Author: jfontain >> >> Update of /cvs/extras/common In directory >> cvs-int.fedora.redhat.com:/tmp/cvs-serv32535 ... > > > Since a very few people still have problems with "make build", > please make sure you have the very latest "common" checkout. The > issue here seems to be that the "cvs up -C tobuild" fails and then > you commit changes to a non-existant tobuild file. Why the cvs up > fails for you and the commit doesn't, would need to be investigated > by somebody. The very first thing I did was a cvs update... Anyway, I cleaned everything up and did a fresh cvs co. I hope this does not happen again... Thanks for your help. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC0Q/OkG/MMvcT1qQRAoEtAJ0f+oOFT8D2nS5p140dprHyFFpRqACfSFsR n7mQMIZKyAC21JBAxCbgCmc= =8QyS -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Sun Jul 10 14:08:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 10 Jul 2005 10:08:53 -0400 Subject: Maintenance of python-docutils In-Reply-To: <42D0FC09.9010208@freshfoo.com> References: <42D0FC09.9010208@freshfoo.com> Message-ID: <1121004533.22153.57.camel@cutter> On Sun, 2005-07-10 at 20:44 +1000, Menno Smits wrote: > Hi all, > > I intend to take over maintenance of the python-docutils package from > Toshio Kuratomi (toshio at tiki-lounge.com) starting today, until he has > reliable internet access again. This has been approved by Toshio. > > My bugzilla account is: menno at freshfoo.com > > Could I please also have permission to update the wiki pages? > What's your wiki username? -sv From skvidal at phy.duke.edu Sun Jul 10 14:09:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 10 Jul 2005 10:09:51 -0400 Subject: common tobuild,1.1888,1.1889 In-Reply-To: <42D10FCE.9090308@free.fr> References: <200507101052.j6AAqDRA032552@cvs-int.fedora.redhat.com> <20050710133943.5dd81e1e.bugs.michael@gmx.net> <42D10FCE.9090308@free.fr> Message-ID: <1121004591.22153.59.camel@cutter> On Sun, 2005-07-10 at 14:08 +0200, Jean-Luc Fontaine wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Schwendt wrote: > > > On Sun, 10 Jul 2005 06:52:13 -0400, Jean-Luc Fontaine wrote: > > > >> Author: jfontain > >> > >> Update of /cvs/extras/common In directory > >> cvs-int.fedora.redhat.com:/tmp/cvs-serv32535 ... > > > > > > Since a very few people still have problems with "make build", > > please make sure you have the very latest "common" checkout. The > > issue here seems to be that the "cvs up -C tobuild" fails and then > > you commit changes to a non-existant tobuild file. Why the cvs up > > fails for you and the commit doesn't, would need to be investigated > > by somebody. > > The very first thing I did was a cvs update... > Anyway, I cleaned everything up and did a fresh cvs co. > I hope this does not happen again... > Thanks for your help. > The only problem is that make builds won't do anything right now. read your email on -maintainers and here. -sv From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 10 15:04:53 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 10 Jul 2005 17:04:53 +0200 Subject: New package: msmtp In-Reply-To: <20050709172115.GA28215@arctangent.net> (Taylor Stearns's message of "Sat, 9 Jul 2005 13:21:15 -0400") References: <20050622215328.GA9276@arctangent.net> <20050709172115.GA28215@arctangent.net> Message-ID: <87vf3ik8h6.fsf@kosh.bigo.ensc.de> taylor at haleph.com (Taylor Stearns) writes: > http://www.haleph.com/download/rpms/msmtp-1.4.2-1.src.rpm > > I would appreciate comments and/or criticism (or sponsorship). > Thanks. There should be added an '|| :' to the 'install-info' scriptlets. Else, they will fail with '--excludedocs' or certain %_netsharedpaths. Man-pages and info files do not need to be tagged with '%doc'; rpm does this automatically. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From adrian at lisas.de Sun Jul 10 16:53:55 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 10 Jul 2005 18:53:55 +0200 Subject: Request for Review: Rekall and dependencies In-Reply-To: <1119238318.11411.8.camel@localhost.localdomain> References: <1119238318.11411.8.camel@localhost.localdomain> Message-ID: <20050710165355.GA16609@lisas.de> On Sun, Jun 19, 2005 at 10:31:58PM -0500, Tom 'spot' Callaway wrote: > SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-1.src.rpm > SPEC: http://auroralinux.org/people/spot/review/xbsql.spec Doesn't build in mock without BR: ncurses-devel The description is very long. A shorter one without every feature described int detail would be much nicer. Adrian From roland at redhat.com Sun Jul 10 19:16:09 2005 From: roland at redhat.com (Roland McGrath) Date: Sun, 10 Jul 2005 12:16:09 -0700 (PDT) Subject: Request for review: cogito Message-ID: <20050710191609.1995B1809FD@magilla.sf.frob.com> In http://people.redhat.com/~roland/fedora/4/ please find cogito.spec, as well as a src.rpm and repodata you can use to install the binaries there. This is one of the GIT-based SCM tools, and apparently one of the most straightforward ways to track Linus's kernel development. I started with an upstream rpm and cleaned up the spec file. It's pretty trivial. I haven't actually put any packages into extras before, so I might have overlooked some conventions. Please advise. Thanks, Roland From tcallawa at redhat.com Sun Jul 10 19:19:04 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 10 Jul 2005 14:19:04 -0500 Subject: Request for Review: Rekall and dependencies In-Reply-To: <20050710165355.GA16609@lisas.de> References: <1119238318.11411.8.camel@localhost.localdomain> <20050710165355.GA16609@lisas.de> Message-ID: <1121023144.22400.57.camel@localhost.localdomain> On Sun, 2005-07-10 at 18:53 +0200, Adrian Reber wrote: > On Sun, Jun 19, 2005 at 10:31:58PM -0500, Tom 'spot' Callaway wrote: > > SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-1.src.rpm > > SPEC: http://auroralinux.org/people/spot/review/xbsql.spec > > Doesn't build in mock without BR: ncurses-devel > The description is very long. A shorter one without every feature > described int detail would be much nicer. Both items fixed: SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-2.src.rpm SPEC: http://auroralinux.org/people/spot/review/xbsql.spec Please re-review/approve. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ermeyers at adelphia.net Sun Jul 10 19:19:28 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Sun, 10 Jul 2005 15:19:28 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507101519.58565.ermeyers@adelphia.net> On 7/9/05, Jeff Spaleta wrote: > Feel free to delibrately name people whom I should actively poke in the eye. Jeff, (and others) I also have that great bonehead-mistake capacity of yours, and I have the problem understood, but maybe not the big solution. I'm available with _lots_ of time, to help Fedora-Extras, and to learn in the process. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sun Jul 10 19:22:21 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 10 Jul 2005 14:22:21 -0500 Subject: Request for review: cogito In-Reply-To: <20050710191609.1995B1809FD@magilla.sf.frob.com> References: <20050710191609.1995B1809FD@magilla.sf.frob.com> Message-ID: <1121023341.22400.60.camel@localhost.localdomain> On Sun, 2005-07-10 at 12:16 -0700, Roland McGrath wrote: > In http://people.redhat.com/~roland/fedora/4/ please find cogito.spec, > as well as a src.rpm and repodata you can use to install the binaries there. > > This is one of the GIT-based SCM tools, and apparently one of the most > straightforward ways to track Linus's kernel development. > > I started with an upstream rpm and cleaned up the spec file. It's pretty > trivial. I haven't actually put any packages into extras before, so I > might have overlooked some conventions. Please advise. Neil Horman, Chris Wright, and now you have all expressed interest in maintaining cogito. Previous requests were halted, due to concerns about the maturity level of the software. I suspect at this point its fine (and there is obviously demand). The three of you should figure out who will own this, then I'll be happy to review the end package. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From roland at redhat.com Sun Jul 10 19:33:37 2005 From: roland at redhat.com (Roland McGrath) Date: Sun, 10 Jul 2005 12:33:37 -0700 (PDT) Subject: Request for review: cogito In-Reply-To: Tom 'spot' Callaway's message of Sunday, 10 July 2005 14:22:21 -0500 <1121023341.22400.60.camel@localhost.localdomain> Message-ID: <20050710193337.F078E1809FD@magilla.sf.frob.com> > Neil Horman, Chris Wright, and now you have all expressed interest in > maintaining cogito. Previous requests were halted, due to concerns about > the maturity level of the software. I suspect at this point its fine > (and there is obviously demand). The three of you should figure out who > will own this, then I'll be happy to review the end package. I have no great desire to do it, just a desire to have it there and a willingness to help make it happen. No matter how immature it is, we are using it today (and there is nothing very mature available to deal with Linus's repositories). So might as well have it easy to install. If we can't put immature but packageable and usable software into Extras, then we'll just have to have yet another infrastructure like Extras for us to collaborate on the Fedora-standard nonstandard stuff. I don't see why anyone would want that. Thanks, Roland From tcallawa at redhat.com Sun Jul 10 19:44:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 10 Jul 2005 14:44:37 -0500 Subject: Request for review: cogito In-Reply-To: <20050710193337.F078E1809FD@magilla.sf.frob.com> References: <20050710193337.F078E1809FD@magilla.sf.frob.com> Message-ID: <1121024677.22400.63.camel@localhost.localdomain> On Sun, 2005-07-10 at 12:33 -0700, Roland McGrath wrote: > > Neil Horman, Chris Wright, and now you have all expressed interest in > > maintaining cogito. Previous requests were halted, due to concerns about > > the maturity level of the software. I suspect at this point its fine > > (and there is obviously demand). The three of you should figure out who > > will own this, then I'll be happy to review the end package. > > I have no great desire to do it, just a desire to have it there and a > willingness to help make it happen. No matter how immature it is, we are > using it today (and there is nothing very mature available to deal with > Linus's repositories). So might as well have it easy to install. > > If we can't put immature but packageable and usable software into Extras, > then we'll just have to have yet another infrastructure like Extras for us > to collaborate on the Fedora-standard nonstandard stuff. I don't see why > anyone would want that. I agree entirely. I'm not against cogito in the slightest (never have been). I just want to make sure that there is no disagreement in who should be maintaining it. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Sun Jul 10 20:16:04 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 10 Jul 2005 22:16:04 +0200 Subject: Request for review: perl-Maypole (and friends) In-Reply-To: <1120855380.22400.17.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120843084.2892.46.camel@localhost.localdomain> <1120855380.22400.17.camel@localhost.localdomain> Message-ID: <1121026565.30532.420.camel@mccallum.corsepiu.local> On Fri, 2005-07-08 at 15:43 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-08 at 20:18 +0300, Ville Skytt? wrote: > > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > > > So, I am requesting review for perl-Maypole, and the 39 other packages > > > that it needed as dependencies. Now, before everyone freaks and runs the > > > other direction, the vast majority of these packages are perl noarch, > > > straight off the template. > I got bored. ;) All cosmetic issues noted are fixed, new specs and SRPMS > are at http://auroralinux.org/people/spot/review/Maypole > > 36 packages left. :) With this patch below applied, I'd approve your perl-Class-Data-Inheritable rpm. --- perl-Class-Data-Inheritable.spec~ 2005-07-10 22:12:29.000000000 +0200 +++ perl-Class-Data-Inheritable.spec 2005-07-10 22:12:43.000000000 +0200 @@ -40,7 +40,7 @@ %files %defattr(-,root,root,-) -%{perl_vendorlib}/Class/Data +%{perl_vendorlib}/Class %{_mandir}/man3/*.3* Rationale: %{perl_vendorlib}/Class is not owned by any "parent rpm" of this rpm, i.e. Installing and removing your rpm leaves an orphaned %{perl_vendorlib}/Class directory. Ralf From roland at redhat.com Sun Jul 10 20:23:43 2005 From: roland at redhat.com (Roland McGrath) Date: Sun, 10 Jul 2005 13:23:43 -0700 (PDT) Subject: Request for review: cogito In-Reply-To: Tom 'spot' Callaway's message of Sunday, 10 July 2005 14:44:37 -0500 <1121024677.22400.63.camel@localhost.localdomain> Message-ID: <20050710202343.392371809FD@magilla.sf.frob.com> > I agree entirely. I'm not against cogito in the slightest (never have > been). I just want to make sure that there is no disagreement in who > should be maintaining it. I defy anyone to get me to disagree with their assertion on that subject. ;-) It was Chris Wright's upstream rpm that I started with. I (and probably Neil) are set up to check it in as soon as given approval, but I imagine Chris is too if he proposed maintaining it in Extras before. Both of them demonstrate their superior sanity by not responding to email on such issues on the weekend. From jwboyer at jdub.homelinux.org Sun Jul 10 20:38:15 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 10 Jul 2005 15:38:15 -0500 Subject: Request for review: cogito In-Reply-To: <20050710191609.1995B1809FD@magilla.sf.frob.com> References: <20050710191609.1995B1809FD@magilla.sf.frob.com> Message-ID: <1121027895.2685.9.camel@yoda.jdub.homelinux.org> On Sun, 2005-07-10 at 12:16 -0700, Roland McGrath wrote: > In http://people.redhat.com/~roland/fedora/4/ please find cogito.spec, > as well as a src.rpm and repodata you can use to install the binaries there. > > This is one of the GIT-based SCM tools, and apparently one of the most > straightforward ways to track Linus's kernel development. > > I started with an upstream rpm and cleaned up the spec file. It's pretty > trivial. I haven't actually put any packages into extras before, so I > might have overlooked some conventions. Please advise. Is there any way to separate cogito and git into two different packages? That way one could install git apart from cogito. I remember talking to Chris Wright about that a while ago. He mentioned something about the upstream cogito developers doing it this way too. Has that happened yet? thx, josh From adrian at lisas.de Sun Jul 10 20:38:50 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 10 Jul 2005 22:38:50 +0200 Subject: Request for review: unclutter Message-ID: <20050710203850.GA15656@lisas.de> %description Unclutter is a program which runs permanently in the background of an X11 session. It checks on the X11 pointer (cursor) position every few seconds, and when it finds it has not moved (and no buttons are pressed on the mouse, and the cursor is not in the root window) it creates a small sub-window as a child of the window the cursor is in. The new window installs a cursor of size 1x1 but a mask of all 0, ie an invisible cursor. This allows you to see all the text in an xterm or xedit, for example. The human factors crowd would agree it should make things less distracting. http://lisas.de/~adrian/rpm/unclutter-8-1.src.rpm http://lisas.de/~adrian/rpm/unclutter.spec Adrian From roland at redhat.com Sun Jul 10 20:50:13 2005 From: roland at redhat.com (Roland McGrath) Date: Sun, 10 Jul 2005 13:50:13 -0700 (PDT) Subject: Request for review: cogito In-Reply-To: Josh Boyer's message of Sunday, 10 July 2005 15:38:15 -0500 <1121027895.2685.9.camel@yoda.jdub.homelinux.org> Message-ID: <20050710205013.91A371809FD@magilla.sf.frob.com> > Is there any way to separate cogito and git into two different packages? > That way one could install git apart from cogito. The upstream cogito is a unified package as it stands. From fedora at camperquake.de Sun Jul 10 20:56:19 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 10 Jul 2005 22:56:19 +0200 Subject: Request for review: unclutter In-Reply-To: <20050710203850.GA15656@lisas.de> References: <20050710203850.GA15656@lisas.de> Message-ID: <20050710205619.GB15672@ryoko.camperquake.de> On Sun, Jul 10, 2005 at 10:38:50PM +0200, Adrian Reber wrote: > Unclutter is a program which runs permanently in the background of an X11 > session. It checks on the X11 pointer (cursor) position every few seconds, and > when it finds it has not moved (and no buttons are pressed on the mouse, and > the cursor is not in the root window) it creates a small sub-window as a child > of the window the cursor is in. The new window installs a cursor of size 1x1 > but a mask of all 0, ie an invisible cursor. This allows you to see all the > text in an xterm or xedit, for example. The human factors crowd would agree it > should make things less distracting. While I think this is certainly useful and salute the inclusion of this program, I find the method employed to hide the cursor absolutely disgusting :) On the other hand, I have fought with NX (and the included X tree) for most of the day, so I may be a little biased. From jwboyer at jdub.homelinux.org Sun Jul 10 20:56:54 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 10 Jul 2005 15:56:54 -0500 Subject: Request for review: cogito In-Reply-To: <20050710205013.91A371809FD@magilla.sf.frob.com> References: <20050710205013.91A371809FD@magilla.sf.frob.com> Message-ID: <1121029014.2685.12.camel@yoda.jdub.homelinux.org> On Sun, 2005-07-10 at 13:50 -0700, Roland McGrath wrote: > > Is there any way to separate cogito and git into two different packages? > > That way one could install git apart from cogito. > > The upstream cogito is a unified package as it stands. Crap. If it ever decides to depend on git instead of include it, can I assume that the package will be changed to depend on a new git package? josh From lmacken at redhat.com Sun Jul 10 23:38:20 2005 From: lmacken at redhat.com (Luke Macken) Date: Sun, 10 Jul 2005 19:38:20 -0400 Subject: Request for Review: nethack Message-ID: <20050710233820.GA4963@tomservo.boston.redhat.com> I noticed that we only have a graphical nethack version in extras (falconseye), which does not come close to satisfying my ASCII dungeon cravings. So I decided to package up the game that almost caused me to fail out of college, NetHack. - - - Description: NetHack is a single player dungeon exploration game that runs on a wide variety of computer systems, with a variety of graphical and text interfaces all using the same game engine. Unlike many other Dungeons & Dragons-inspired games, the emphasis in NetHack is on discovering the detail of the dungeon and not simply killing everything in sight - in fact, killing everything in sight is a good way to die quickly. Each game presents a different landscape - the random number generator provides an essentially unlimited number of variations of the dungeon and its denizens to be discovered by the player in one of a number of characters: you can pick your race, your role, and your gender. - - - SPEC: http://people.redhat.com/lmacken/nethack.spec SRPM: http://people.redhat.com/lmacken/nethack-3.4.3-1.src.rpm Thanks, luke From jwboyer at jdub.homelinux.org Sun Jul 10 23:54:54 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 10 Jul 2005 18:54:54 -0500 Subject: Request for review: cogito In-Reply-To: <20050710191609.1995B1809FD@magilla.sf.frob.com> References: <20050710191609.1995B1809FD@magilla.sf.frob.com> Message-ID: <1121039694.2685.25.camel@yoda.jdub.homelinux.org> On Sun, 2005-07-10 at 12:16 -0700, Roland McGrath wrote: > In http://people.redhat.com/~roland/fedora/4/ please find cogito.spec, > as well as a src.rpm and repodata you can use to install the binaries there. > > This is one of the GIT-based SCM tools, and apparently one of the most > straightforward ways to track Linus's kernel development. > > I started with an upstream rpm and cleaned up the spec file. It's pretty > trivial. I haven't actually put any packages into extras before, so I > might have overlooked some conventions. Please advise. Ok, regardless of the unified or broken out git issue, I think this package is ready to be included. Here are a few questions on the spec file: - Is there a reason the Requires: list files instead of their respective packages? - coreutils is probably not needed as a requires since everything requires it. No harm in it being there though - Is the Obsoletes: git needed? In my limited knowledge, I'm just wondering if this will cause upgrade problems when/if cogito and git are split into separate packages in the future. Other than that, I see no problems. I look forward to using it :). josh From mfleming at enlartenment.com Mon Jul 11 00:33:57 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Mon, 11 Jul 2005 10:33:57 +1000 Subject: Request for Review: nethack In-Reply-To: <20050710233820.GA4963@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> Message-ID: <20050711003357.GA4401@enlartenment.com> On Sun, Jul 10, 2005 at 07:38:20PM -0400, Luke Macken waffled thusly: > I noticed that we only have a graphical nethack version in extras > (falconseye), which does not come close to satisfying my ASCII dungeon > cravings. So I decided to package up the game that almost caused me to > fail out of college, NetHack. Thanks for this - I'm currently having an "interesting time" packaging zangband so this effort is more than welcome (I'm hanging out for a bit of ASCII hack myself) Good: - Builds in mock - Runs OK - Thoughtful of you to provide a .desktop file even for the terminal version. - Specfile clear and easily followed. - Good idea to Not-Bad-But-Not-So-"Good".. /usr/games/nethack should really be /usr/share/games/nethack? (I'm thinking of the filesystem hierarchy standard here..) RPMlint says the following: W: nethack unstripped-binary-or-object /usr/games/nethack/nethack E: nethack zero-length /var/games/nethack/logfile E: nethack zero-length /var/games/nethack/record E: nethack zero-length /var/games/nethack/perm E: nethack non-standard-dir-perm /var/games/nethack 0775 E: nethack non-standard-executable-perm /usr/games/nethack/nethack 02755 E: nethack non-standard-dir-perm /var/games/nethack/save 0775 Mind you, these are expected for a game structured like nethack so I'm willing to overlook them. Gets the thumbs-up from me. Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From lmacken at redhat.com Mon Jul 11 00:57:45 2005 From: lmacken at redhat.com (Luke Macken) Date: Sun, 10 Jul 2005 20:57:45 -0400 Subject: Request for Review: nethack In-Reply-To: <20050711003357.GA4401@enlartenment.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050711003357.GA4401@enlartenment.com> Message-ID: <20050711005745.GA5213@tomservo.boston.redhat.com> On Mon, Jul 11, 2005 at 10:33:57AM +1000, Michael Fleming wrote: | Not-Bad-But-Not-So-"Good".. | | /usr/games/nethack should really be /usr/share/games/nethack? (I'm | thinking of the filesystem hierarchy standard here..) Since /usr/share is for arch-independent data, everything except the 'nethack' and 'recover' binaries would be able to go there. Where do you recommend these files go ? I tried to stick to the FHS as much as possible, and broke off the usual /usr/games/lib/nethackdir standard into separate game (/usr/games/nethack) and state (/var/games/nethack) directories. | RPMlint says the following: | | W: nethack unstripped-binary-or-object /usr/games/nethack/nethack | E: nethack zero-length /var/games/nethack/logfile | E: nethack zero-length /var/games/nethack/record | E: nethack zero-length /var/games/nethack/perm | E: nethack non-standard-dir-perm /var/games/nethack 0775 | E: nethack non-standard-executable-perm /usr/games/nethack/nethack 02755 | E: nethack non-standard-dir-perm /var/games/nethack/save 0775 | | Mind you, these are expected for a game structured like nethack so I'm | willing to overlook them. I figured as much. Thanks, luke From menno-fedora at freshfoo.com Mon Jul 11 01:20:43 2005 From: menno-fedora at freshfoo.com (Menno Smits) Date: Mon, 11 Jul 2005 11:20:43 +1000 Subject: Maintenance of python-docutils In-Reply-To: <1121004533.22153.57.camel@cutter> References: <42D0FC09.9010208@freshfoo.com> <1121004533.22153.57.camel@cutter> Message-ID: <42D1C96B.2010303@freshfoo.com> seth vidal wrote: >>Could I please also have permission to update the wiki pages? >> > > > What's your wiki username? MennoSmits Thanks, Menno From skvidal at phy.duke.edu Mon Jul 11 01:30:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 10 Jul 2005 21:30:39 -0400 Subject: Maintenance of python-docutils In-Reply-To: <42D1C96B.2010303@freshfoo.com> References: <42D0FC09.9010208@freshfoo.com> <1121004533.22153.57.camel@cutter> <42D1C96B.2010303@freshfoo.com> Message-ID: <1121045439.3102.45.camel@cutter> On Mon, 2005-07-11 at 11:20 +1000, Menno Smits wrote: > MennoSmits done. -sv From tcallawa at redhat.com Mon Jul 11 01:54:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 10 Jul 2005 20:54:39 -0500 Subject: Request for review: perl-Maypole (and friends) In-Reply-To: <1121026565.30532.420.camel@mccallum.corsepiu.local> References: <1120768388.9303.40.camel@localhost.localdomain> <1120843084.2892.46.camel@localhost.localdomain> <1120855380.22400.17.camel@localhost.localdomain> <1121026565.30532.420.camel@mccallum.corsepiu.local> Message-ID: <1121046879.22400.75.camel@localhost.localdomain> On Sun, 2005-07-10 at 22:16 +0200, Ralf Corsepius wrote: > On Fri, 2005-07-08 at 15:43 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2005-07-08 at 20:18 +0300, Ville Skytt? wrote: > > > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > > > > > So, I am requesting review for perl-Maypole, and the 39 other packages > > > > that it needed as dependencies. Now, before everyone freaks and runs the > > > > other direction, the vast majority of these packages are perl noarch, > > > > straight off the template. > > > I got bored. ;) All cosmetic issues noted are fixed, new specs and SRPMS > > are at http://auroralinux.org/people/spot/review/Maypole > > > > 36 packages left. :) > With this patch below applied, I'd approve your > perl-Class-Data-Inheritable rpm. Makes sense. :) Patch applied, package checked into cvs. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Mon Jul 11 02:01:30 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 10 Jul 2005 21:01:30 -0500 Subject: Request for Review: nethack In-Reply-To: <20050711005745.GA5213@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050711003357.GA4401@enlartenment.com> <20050711005745.GA5213@tomservo.boston.redhat.com> Message-ID: <1121047290.22400.79.camel@localhost.localdomain> On Sun, 2005-07-10 at 20:57 -0400, Luke Macken wrote: > On Mon, Jul 11, 2005 at 10:33:57AM +1000, Michael Fleming wrote: > | Not-Bad-But-Not-So-"Good".. > | > | /usr/games/nethack should really be /usr/share/games/nethack? (I'm > | thinking of the filesystem hierarchy standard here..) > > Since /usr/share is for arch-independent data, everything except the > 'nethack' and 'recover' binaries would be able to go there. Where do > you recommend these files go ? "recover" is a very very generic name. If this ends up in the default $PATH, please rename it to "nethack-recover". With that caveat, I see no reason these files can't live in %{_bindir} (I was always annoyed that the default location wasn't in my path). > I tried to stick to the FHS as much as possible, and broke off the usual > /usr/games/lib/nethackdir standard into separate game > (/usr/games/nethack) and state (/var/games/nethack) directories. > > | RPMlint says the following: > | > | W: nethack unstripped-binary-or-object /usr/games/nethack/nethack This usually means that the file is not chmod +x. Try doing that in %install, it should make the error go away. > | E: nethack zero-length /var/games/nethack/logfile > | E: nethack zero-length /var/games/nethack/record > | E: nethack zero-length /var/games/nethack/perm All of these will likely go away if you make them %ghost. > | E: nethack non-standard-dir-perm /var/games/nethack 0775 > | E: nethack non-standard-executable-perm /usr/games/nethack/nethack 02755 > | E: nethack non-standard-dir-perm /var/games/nethack/save 0775 Nethack shouldn't need to be using these odd permissions. Try just 775 and 755. Also, last time I looked, falconeye and nethack conflicted when both installed. Please double check that this is not the case. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mricon at gmail.com Mon Jul 11 03:56:34 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 10 Jul 2005 23:56:34 -0400 Subject: Request for Review: nethack In-Reply-To: <20050710233820.GA4963@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> Message-ID: On 10/07/05, Luke Macken wrote: > I noticed that we only have a graphical nethack version in extras > (falconseye), which does not come close to satisfying my ASCII dungeon > cravings. Not to mention that Falcon's Eye eats 100% CPU just doing nothing. Not so welcome on a laptop. :( Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From notting at redhat.com Mon Jul 11 04:28:58 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jul 2005 00:28:58 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> Message-ID: <20050711042857.GA7425@nostromo.devel.redhat.com> Chris Ricker (kaboom at oobleck.net) said: > I think something like comps.xml, but for extras, would be a better fit in > terms of goals of having groups of stuff easily installable with yum > groupinstall and similar. > > The catch is figuring out how to group though. Sometimes you can do it by > function (games group would probably be popular) but sometimes function > doesn't make much sense (we probably don't want a windowmanagers group, we > want a group for E + all its little applets, for blackbox + all its little > applets, etc) Yeah, that's the problematic thing here. For example, when the currently existing comps.xml was made, some of the stuff was easy (all Games grouped together, Development Tools, etc.) However, that only accounts for a subset of packages. Realistically, random libraries shouldn't be listed, except perhaps for the -devel pacakge in one of the development library groups. And some of the packages defy simple categorization, unless you have a group for each package. Which... no. Bill From ville.skytta at iki.fi Mon Jul 11 06:50:20 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 09:50:20 +0300 Subject: Request for Review: nethack In-Reply-To: <20050710233820.GA4963@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> Message-ID: <1121064620.2892.192.camel@localhost.localdomain> On Sun, 2005-07-10 at 19:38 -0400, Luke Macken wrote: > I noticed that we only have a graphical nethack version in extras > (falconseye), which does not come close to satisfying my ASCII dungeon > cravings. It includes the regular ASCII NetHack, too. From ville.skytta at iki.fi Mon Jul 11 07:00:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 10:00:04 +0300 Subject: Request for Review: nethack In-Reply-To: <1121064620.2892.192.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> Message-ID: <1121065204.2892.195.camel@localhost.localdomain> On Mon, 2005-07-11 at 09:50 +0300, Ville Skytt? wrote: > On Sun, 2005-07-10 at 19:38 -0400, Luke Macken wrote: > > I noticed that we only have a graphical nethack version in extras > > (falconseye), which does not come close to satisfying my ASCII dungeon > > cravings. > > It includes the regular ASCII NetHack, too. ...and to invoke it, "NETHACKOPTIONS=windowtype:tty nethack". From paul at city-fan.org Mon Jul 11 07:46:31 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 11 Jul 2005 08:46:31 +0100 Subject: Request for review: cogito In-Reply-To: <1121039694.2685.25.camel@yoda.jdub.homelinux.org> References: <20050710191609.1995B1809FD@magilla.sf.frob.com> <1121039694.2685.25.camel@yoda.jdub.homelinux.org> Message-ID: <1121067991.15736.360.camel@laurel.intra.city-fan.org> On Sun, 2005-07-10 at 18:54 -0500, Josh Boyer wrote: > - Is the Obsoletes: git needed? In my limited knowledge, I'm just > wondering if this will cause upgrade problems when/if cogito and git are > split into separate packages in the future. Isn't the standard thing to do here to use a versioned Obsoletes:, plus a Provides:? e.g. Obsoletes: git < %{version}-%{release} Provides: git So a later-versioned package can split git off into a separate package and not be obsoleted by this one, and anything that depends on git can be satisfied by installing this package. Paul. -- Paul Howarth From kairaven at arcor.de Mon Jul 11 07:49:07 2005 From: kairaven at arcor.de (Kai Raven) Date: Mon, 11 Jul 2005 09:49:07 +0200 Subject: Liferea description Message-ID: <20050711094907.5824434e@localhost.localdomain> Hi, the description for the Liferea RPM says: "...and show their contents using GtkHTML." Because Liferea is capable to use Mozilla too, the description could be changed to: "...and show their contents using Mozilla or GtkHTML2." -- Ciao Kai WWW: http://kai.iks-jena.de/ Blog: http://rabenhorst.blogweb.de/ OpenPGP: D6E995A0 Jabber: kraven at jabber.ccc.de From oliver at linux-kernel.at Mon Jul 11 07:57:46 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jul 2005 09:57:46 +0200 Subject: Request for review: icmpdn In-Reply-To: <1120956701.29955.0.camel@pc7.dolda2000.com> References: <200507092118.j69LIfgo014313@mail.linux-kernel.at> <1120956701.29955.0.camel@pc7.dolda2000.com> Message-ID: <42D2267A.7080003@linux-kernel.at> On 07/10/2005 02:51 AM, Fredrik Tolf wrote: > On Sat, 2005-07-09 at 23:19 +0200, Oliver Falk wrote: > >>>On Fri, 2005-07-08 at 09:01 +0200, Oliver Falk wrote: >>> >>>>On 07/07/2005 09:41 PM, Fredrik Tolf wrote: >>>> >>>>>Same links as before, but I can repeat them for the sake of >>>>>completeness: >>>>> >>>>> >>>>> >>>>>I hope you find this OK. >>>> >>>>Approval sent out. >>> >>>Thank you! >>> >>>I still don't have my CVS account, though, so will anyone be >>>as kind as to CVS sponsor this for the moment? >> >>* Imported >>* Requested Bugzilla Entry for you >>* Requested CVSSync for FC3, FC4 >>* Requested initial build on devel branch >> >>I hope this is OK for you? > > > Thank you very much! I guess that should be all that I had planned to > do, but then again, I'm new to the Extras system. I'll have to read up > on it on the Wiki once I get my account. > > Again, thanks for all your help! U r welcome. :-) I'll have a look if the build went fine and Bugzilla entry, as well as the cvssync have been done... Best, Oliver From fedora at camperquake.de Mon Jul 11 11:09:26 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 11 Jul 2005 13:09:26 +0200 Subject: Request for Review: nethack In-Reply-To: <1121065204.2892.195.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> Message-ID: <20050711130926.779bb9db@nausicaa.camperquake.de> Hi. Ville Skytt? wrote: > ...and to invoke it, "NETHACKOPTIONS=windowtype:tty nethack". Maybe there ought to be a shell script included that does that? nethack-tty or something like that. -- Go not unto the Usenet for advice, for you will be told both yea and nay (and quite a few things that just have nothing at all to do with the question). From lmacken at redhat.com Mon Jul 11 12:36:54 2005 From: lmacken at redhat.com (Luke Macken) Date: Mon, 11 Jul 2005 08:36:54 -0400 Subject: Request for Review: nethack In-Reply-To: <1121065204.2892.195.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> Message-ID: <20050711123654.GA6289@tomservo.boston.redhat.com> On Mon, Jul 11, 2005 at 10:00:04AM +0300, Ville Skytt? wrote: | On Mon, 2005-07-11 at 09:50 +0300, Ville Skytt? wrote: | > On Sun, 2005-07-10 at 19:38 -0400, Luke Macken wrote: | > > I noticed that we only have a graphical nethack version in extras | > > (falconseye), which does not come close to satisfying my ASCII dungeon | > > cravings. | > | > It includes the regular ASCII NetHack, too. | | ...and to invoke it, "NETHACKOPTIONS=windowtype:tty nethack". That's great and all (for being NetHack 4.3.1), but I still think we need vanilla NetHack in the tree as well so we can use the latest versions. luke From oliver at linux-kernel.at Mon Jul 11 14:17:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jul 2005 16:17:57 +0200 Subject: Request for review: icmpdn In-Reply-To: <42D2267A.7080003@linux-kernel.at> References: <200507092118.j69LIfgo014313@mail.linux-kernel.at> <1120956701.29955.0.camel@pc7.dolda2000.com> <42D2267A.7080003@linux-kernel.at> Message-ID: <42D27F95.1030008@linux-kernel.at> Hi Fredrik! On 07/11/2005 09:57 AM, Oliver Falk wrote: [ ... ] > I'll have a look if the build went fine and Bugzilla entry, as well as > the cvssync have been done... Bugzilla entry has been created: https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras CVSSync not yet done (http://fedoraproject.org/wiki/Extras/CVSSyncNeeded) Best, Oliver From oliver at linux-kernel.at Mon Jul 11 14:23:18 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jul 2005 16:23:18 +0200 Subject: Request for review: bwm-ng In-Reply-To: <42CE7809.3090202@linux-kernel.at> References: <42CE7809.3090202@linux-kernel.at> Message-ID: <42D280D6.6040201@linux-kernel.at> On 07/08/2005 02:56 PM, Oliver Falk wrote: > bwm-ng is still in my pipe and here we go: > > Summary: A bandwidth monitor > > Description > A small and simple curses base bandwidth monitor. No big features. > > SPEC & SRPM: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/bwm-ng > > > (bwm-ng uses the libstatgrab package, which was included today!). > > Please review/approve. Noone saw this, did you? Best, Oliver From ville.skytta at iki.fi Mon Jul 11 15:00:15 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 18:00:15 +0300 Subject: Request for Review: nethack In-Reply-To: <20050711123654.GA6289@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> <20050711123654.GA6289@tomservo.boston.redhat.com> Message-ID: <1121094015.2892.221.camel@localhost.localdomain> On Mon, 2005-07-11 at 08:36 -0400, Luke Macken wrote: > On Mon, Jul 11, 2005 at 10:00:04AM +0300, Ville Skytt? wrote: > | On Mon, 2005-07-11 at 09:50 +0300, Ville Skytt? wrote: > | > On Sun, 2005-07-10 at 19:38 -0400, Luke Macken wrote: > | > > I noticed that we only have a graphical nethack version in extras > | > > (falconseye), which does not come close to satisfying my ASCII dungeon > | > > cravings. > | > > | > It includes the regular ASCII NetHack, too. > | > | ...and to invoke it, "NETHACKOPTIONS=windowtype:tty nethack". > > That's great and all (for being NetHack 4.3.1), but I still think we > need vanilla NetHack in the tree as well so we can use the latest > versions. I think there's a way to get both of best worlds; how about this plan: 1) Ask the Falcon's Eye upstream if he's going to release an update soon. Despite of the rumours of the project being dead, he has repeatedly stated that a new version is in the works in public forums (albeit not too recently AFAIK). Wait until end of this week for his reply. 2a) If NHFE maintainer doesn't reply or the new NHFE is far away, switch the Extras package to the more lively Vulture's Eye fork, http://www.darkarts.co.za/projects/vultures That includes NetHack 3.4.3 (the latest one). 2b) If NHFE upstream responds saying new NHFE including the latest "vanilla" NH is just around the corner, wait for that. 3) No matter what the conclusion from 1) and 2) above is, tune the current nethack-* package in Extras so that running "nethack" launches the tty version, and "nethack-falconseye" (or -vultureseye) the GUI version. And add a menu entry for the tty version, too. And note availability of the tty version more prominently in the package's description. Thoughts? I think it would be inefficient use of resources to maintain two NH packages in Extras, given that we can most likely get both the latest and greatest traditional NetHack, as well as the GUI eye candy in the same package. From gdk at redhat.com Mon Jul 11 15:04:04 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 11 Jul 2005 11:04:04 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> Message-ID: +1 to: * Request for comps changes to wiki * Small team of folks managing these requests --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Sat, 9 Jul 2005, Konstantin Ryabitsev wrote: > On 09/07/05, Jeff Spaleta wrote: > > As a regular cvs user I think you need 3 seperate operations > > 1)a make command that lets you pull down the most current list of > > defined group tags > > 2)a make command to add your package to a set of groups > > 3a make command to remove your package from a set of groups. > > > > > > In the meantime however... would a wikipage like what we are using for > > bugzilla entries be a start? A wiki page where maintainers can > > request group adds and removals. And a "small:" group of maintainers > > in charge of comps.xml can integrate or deny those requests? > > I think we should combine -- a wikipage to suggest new groups, > mandatory group packages, group meta-dependencies, and to handle stuff > like i18n translations. Plus cvs tags for assigning the package as > "optional" into already defined groups. > > That could work reasonably well. > > Regards, > -- > Konstantin Ryabitsev > Zlotniks, INC > > "???????? ?????????? ????? ? ??????? ???? ?????." > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From dwmw2 at infradead.org Mon Jul 11 15:13:10 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 11 Jul 2005 16:13:10 +0100 Subject: Request for Review: nethack In-Reply-To: <20050711005745.GA5213@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050711003357.GA4401@enlartenment.com> <20050711005745.GA5213@tomservo.boston.redhat.com> Message-ID: <1121094791.27264.121.camel@hades.cambridge.redhat.com> On Sun, 2005-07-10 at 20:57 -0400, Luke Macken wrote: > Since /usr/share is for arch-independent data, everything except the > 'nethack' and 'recover' binaries would be able to go there. Where do > you recommend these files go ? Last time I checked, the data files weren't arch-independent. They vary not only with word size and endianness, but with other struct layout changes. Data files generated on i386 aren't usable on ARM, for example. -- dwmw2 From ville.skytta at iki.fi Mon Jul 11 15:13:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 18:13:38 +0300 Subject: Request for Review: nethack In-Reply-To: <20050711130926.779bb9db@nausicaa.camperquake.de> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> <20050711130926.779bb9db@nausicaa.camperquake.de> Message-ID: <1121094818.2892.227.camel@localhost.localdomain> On Mon, 2005-07-11 at 13:09 +0200, Ralf Ertzinger wrote: > Hi. > > Ville Skytt? wrote: > > > ...and to invoke it, "NETHACKOPTIONS=windowtype:tty nethack". > > Maybe there ought to be a shell script included that does > that? nethack-tty or something like that. Yep, that's doable, NETHACKOPTIONS from the environment takes precedence over ~/.nethackrc. But perhaps just "nethack" for the tty version, and "nethack-$fancyguiversion" for the other one. From lmacken at redhat.com Mon Jul 11 15:07:09 2005 From: lmacken at redhat.com (Luke Macken) Date: Mon, 11 Jul 2005 11:07:09 -0400 Subject: Request for Review: nethack In-Reply-To: <1121094015.2892.221.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> <20050711123654.GA6289@tomservo.boston.redhat.com> <1121094015.2892.221.camel@localhost.localdomain> Message-ID: <20050711150709.GB6416@tomservo.boston.redhat.com> On Mon, Jul 11, 2005 at 06:00:15PM +0300, Ville Skytt? wrote: | I think there's a way to get both of best worlds; how about this plan: | | 1) Ask the Falcon's Eye upstream if he's going to release an update | soon. Despite of the rumours of the project being dead, he has | repeatedly stated that a new version is in the works in public forums | (albeit not too recently AFAIK). Wait until end of this week for his | reply. ...so we are going to have to bug the Falcon's Eye developers every time we want a newer version of NetHack ? I'd rather follow NetHack development, than some questionable fork. | 2a) If NHFE maintainer doesn't reply or the new NHFE is far away, switch | the Extras package to the more lively Vulture's Eye fork, | http://www.darkarts.co.za/projects/vultures | That includes NetHack 3.4.3 (the latest one). | | 2b) If NHFE upstream responds saying new NHFE including the latest | "vanilla" NH is just around the corner, wait for that. | | 3) No matter what the conclusion from 1) and 2) above is, tune the | current nethack-* package in Extras so that running "nethack" launches | the tty version, and "nethack-falconseye" (or -vultureseye) the GUI | version. And add a menu entry for the tty version, too. And note | availability of the tty version more prominently in the package's | description. | | Thoughts? I think it would be inefficient use of resources to maintain | two NH packages in Extras, given that we can most likely get both the | latest and greatest traditional NetHack, as well as the GUI eye candy in | the same package. These graphical frontends are all forks, and offer me nothing but extra crap on my system. I'm not against carrying as many different forks/frontends as humanly possibly, but if you want a 'standard' nethack game with tty and a graphical frontend, the vanilla version can be built with X, qt, or gnome guis as well. I just not seeing how we benefit from restricting Fedora users to install *extremely* unstable graphical versions of a text based game. luke From ville.skytta at iki.fi Mon Jul 11 15:15:39 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 18:15:39 +0300 Subject: Liferea description In-Reply-To: <20050711094907.5824434e@localhost.localdomain> References: <20050711094907.5824434e@localhost.localdomain> Message-ID: <1121094939.2892.229.camel@localhost.localdomain> On Mon, 2005-07-11 at 09:49 +0200, Kai Raven wrote: > Because Liferea is capable to use Mozilla too, the description could be changed > to: > "...and show their contents using Mozilla or GtkHTML2." Or even "...and show their contents." From lmacken at redhat.com Mon Jul 11 15:13:41 2005 From: lmacken at redhat.com (Luke Macken) Date: Mon, 11 Jul 2005 11:13:41 -0400 Subject: Request for Review: nethack In-Reply-To: <1121094791.27264.121.camel@hades.cambridge.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050711003357.GA4401@enlartenment.com> <20050711005745.GA5213@tomservo.boston.redhat.com> <1121094791.27264.121.camel@hades.cambridge.redhat.com> Message-ID: <20050711151341.GC6416@tomservo.boston.redhat.com> On Mon, Jul 11, 2005 at 04:13:10PM +0100, David Woodhouse wrote: | On Sun, 2005-07-10 at 20:57 -0400, Luke Macken wrote: | > Since /usr/share is for arch-independent data, everything except the | > 'nethack' and 'recover' binaries would be able to go there. Where do | > you recommend these files go ? | | Last time I checked, the data files weren't arch-independent. They vary | not only with word size and endianness, but with other struct layout | changes. Data files generated on i386 aren't usable on ARM, for example. Ah, you're right. I only really looked at the top part of the datafile (nhdat), which is just plain text, but the bottom is most likely arch-dependent data. So shall we stick with /usr/games/nethack, or is there are more suitable place for these files? luke From ville.skytta at iki.fi Mon Jul 11 15:46:23 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 18:46:23 +0300 Subject: Request for Review: nethack In-Reply-To: <20050711150709.GB6416@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> <20050711123654.GA6289@tomservo.boston.redhat.com> <1121094015.2892.221.camel@localhost.localdomain> <20050711150709.GB6416@tomservo.boston.redhat.com> Message-ID: <1121096783.2892.258.camel@localhost.localdomain> On Mon, 2005-07-11 at 11:07 -0400, Luke Macken wrote: > ...so we are going to have to bug the Falcon's Eye developers every time > we want a newer version of NetHack ? No, we ask now, and using our best judgement, make a decision. I'm leaning towards Vulture's Eye being the "best" solution right now. > I'd rather follow NetHack > development, than some questionable fork. [...] > These graphical frontends are all forks I don't see them being forks of NetHack any more than let's say the Fedora Core kernel is a fork of Linus' kernel. With people maintaining the non-vanilla version and things working, I see no problem with that. > I'm not against carrying as many different > forks/frontends as humanly possibly, but if you want a 'standard' > nethack game with tty and a graphical frontend, the vanilla version can > be built with X, qt, or gnome guis as well. None of which are anywhere close to the isometric 3D versions. Apples and oranges, and we could most likely easily have them all. > I just not seeing how we > benefit from restricting Fedora users to install *extremely* unstable > graphical versions of a text based game. Where can I read more about this extreme unstability? This thread already contains suggestions how to make the GUI version packaging more friendly for the tty fans, and addresses. And FWIW, I'm definitely one, I don't personally really care much at all about any of the the GUIs. Practically speaking, that means if the vanilla NetHack enters Extras, the GUI version will need a new maintainer. While I'd be happy to let go of it, end users will lose unless someone else steps up. You seem to have strong opinions about this and I guess you'll pursue packaging the vanilla one anyway, so: I'd suggest at least taking a look at the nethack-falconseye specfile, the package is in a pretty good shape at the moment IIRC. Also, suggestions how to handle the inevitable conflicts between the "vanilla" and the GUI one are welcome, and IMO need to be decided/addressed if and before the two are both in Extras. From qspencer at ieee.org Mon Jul 11 16:15:13 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 11 Jul 2005 11:15:13 -0500 Subject: Package name changes Message-ID: <42D29B11.9080005@ieee.org> Hi all, When I imported the GiNaC package to extras, I kept the capitalization in the name (which I admit is odd) so it would match upstream. So, there's now a new release in which the upstream developer has apparently modified the name of the package so that it's all lower case. I probably should have done this to begin with (the Debian package did), but suppose I wanted to now make a switch to a more sane all-lower-case name--how would I go about it? (I haven't yet decided to do this--I just want to figure out what's involved). I've never used the "Obsoletes" in a spec file before, but I suppose that would be needed here? More importantly, would I need to create a new package in CVS that obsoletes the old one, or just put a renamed spec file in the old CVS tree? Lastly, is all of this worth it for a fairly trivial name change? (Note that packages requiring ginac aren't a big problem--there's only one). -Quentin From jspaleta at gmail.com Mon Jul 11 16:17:54 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jul 2005 12:17:54 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> Message-ID: <604aa7910507110917321e58b9@mail.gmail.com> On 7/11/05, Greg DeKoenigsberg wrote: > > +1 to: > * Request for comps changes to wiki > * Small team of folks managing these requests does this mean you are volunteering to help manage those requests ? I dont have that much experience munching comps, so I'm not going to attempt to be responsible for dealing with comps admining alone. I can however help setup the wiki page by which maintainers make requests to whomever the comps admin(s) are going to be. -jef From ville.skytta at iki.fi Mon Jul 11 16:30:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 19:30:38 +0300 Subject: Package name changes In-Reply-To: <42D29B11.9080005@ieee.org> References: <42D29B11.9080005@ieee.org> Message-ID: <1121099438.2892.274.camel@localhost.localdomain> On Mon, 2005-07-11 at 11:15 -0500, Quentin Spencer wrote: > When I imported the GiNaC package to extras, I kept the capitalization > in the name (which I admit is odd) so it would match upstream. So, > there's now a new release in which the upstream developer has apparently > modified the name of the package so that it's all lower case. I probably > should have done this to begin with (the Debian package did), Yep, one easy way to avoid these problems when upstreams change their minds is to always stick with lowercase ;) > but > suppose I wanted to now make a switch to a more sane all-lower-case > name--how would I go about it? (I haven't yet decided to do this--I just > want to figure out what's involved). I've never used the "Obsoletes" in > a spec file before, but I suppose that would be needed here? Obsoletes: GiNaC <= 1.3.1 Provides: GiNaC = %{version}-%{release} > More > importantly, would I need to create a new package in CVS that obsoletes > the old one, or just put a renamed spec file in the old CVS tree? Probably the former, but people who actually know will need to confirm. > Lastly, is all of this worth it for a fairly trivial name change? (Note > that packages requiring ginac aren't a big problem--there's only one). Dunno, you're the maintainer, you decide. When using the Provides: as specified above, even that one package would need no changes right now. Alternatively, if you're anticipating a switch later, keeping the current one as GiNaC and adding "Provides: ginac = %{version}-%{release}" could be worth considering too (which, BTW, wouldn't be a bad idea IMHO for all packages that don't have all-lowercase names, and that's something even rpm(build) could theoretically do under the hood). From orion at cora.nwra.com Mon Jul 11 16:36:31 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Jul 2005 10:36:31 -0600 Subject: photran fortran dev module for eclipse Message-ID: <42D2A00F.9040807@cora.nwra.com> Has anyone considered building a rpm for photran: http://www.photran.org/ ? Are there other fortran modules for eclipse under development that are "better"? I was going to start trying to package it for Extras, but wanted to check with others first. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From kaboom at oobleck.net Mon Jul 11 16:36:14 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 11 Jul 2005 12:36:14 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050711042857.GA7425@nostromo.devel.redhat.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: On Mon, 11 Jul 2005, Bill Nottingham wrote: > Yeah, that's the problematic thing here. For example, when the > currently existing comps.xml was made, some of the stuff was easy > (all Games grouped together, Development Tools, etc.) > > However, that only accounts for a subset of packages. Realistically, > random libraries shouldn't be listed, except perhaps for the -devel > pacakge in one of the development library groups. And some of the > packages defy simple categorization, unless you have a group for each > package. Which... no. How to group is one issue The other is how to include all the Fedora repositories. I realize that livna is not / cannot officially be Fedora, for example, but it would still be nice if this worked for them and others. How will 3rd-party repositories extend? modify comps.xml in FC? or supplemental comps files for each repository? or just not worry about it? or...? later, chris From alex at dalloz.de Mon Jul 11 16:42:33 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Mon, 11 Jul 2005 18:42:33 +0200 Subject: Request for a sponsor and a review of: pam_abl Message-ID: <1121100153.22665.295.camel@serendipity.dogma.lan> Hello fellows! I kindly request for a sponsorship and like to introduce myself with a small package contribution, called pam_abl. pam_abl provides auto blacklisting of hosts and users responsible for repeated failed authentication attempts. Generally configured so that blacklisted users still see normal login prompts but are guaranteed to fail to authenticate. A command line tool allows to query or purge the databases used by the pam_abl module. The home of the software is: http://www.hexten.net/sw/pam_abl/ In my humble opinion this PAM module is useful in time when many of use get hit by massive SSH connection attempts, even dictionary attacks. It has some more flexibility (wider range of configuration) above pam_tally (faillog). SRC.RPM and SPEC file can be taken for a review from: http://www.uni-x.org/pam_abl-0.2.2-20050110.src.rpm http://www.uni-x.org/pam_abl.spec I hope I can come up with a few more packages for Extras soon. Alexander (can be reached on freenode as "Zerberus") -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From notting at redhat.com Mon Jul 11 16:44:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jul 2005 12:44:47 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: <20050711164447.GA12867@nostromo.devel.redhat.com> Chris Ricker (kaboom at oobleck.net) said: > The other is how to include all the Fedora repositories. I realize that > livna is not / cannot officially be Fedora, for example, but it would > still be nice if this worked for them and others. How will 3rd-party > repositories extend? modify comps.xml in FC? or supplemental comps files > for each repository? or just not worry about it? or...? Comps files for each repo. Bill From gdk at redhat.com Mon Jul 11 16:52:08 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 11 Jul 2005 12:52:08 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507110917321e58b9@mail.gmail.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa7910507110917321e58b9@mail.gmail.com> Message-ID: My time is spread pretty thin -- so no, I'm not actually volunteering for this duty. I just think it's a good idea. So what's it take to manage comps.xml? Jeremy? Seth? Anyone? --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Mon, 11 Jul 2005, Jeff Spaleta wrote: > On 7/11/05, Greg DeKoenigsberg wrote: > > > > +1 to: > > * Request for comps changes to wiki > > * Small team of folks managing these requests > > does this mean you are volunteering to help manage those requests ? > I dont have that much experience munching comps, so I'm not going to > attempt to be responsible for dealing with comps admining alone. I > can however help setup the wiki page by which maintainers make > requests to whomever the comps admin(s) are going to be. > > -jef > From jpo at di.uminho.pt Mon Jul 11 16:55:08 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Mon, 11 Jul 2005 17:55:08 +0100 Subject: New Package: perl-Apache-LogRegex In-Reply-To: <200507030026.10119.ghenry@suretecsystems.com> References: <200507030026.10119.ghenry@suretecsystems.com> Message-ID: <42D2A46C.3010502@di.uminho.pt> Gavin, > SRPM: > http://www.perl.me.uk/downloads/modules/perl-Apache-LogRegex-1.2-1.src.rpm > SPEC: http://www.perl.me.uk/downloads/modules/perl-Apache-LogRegex.spec Needswork: * The license information is incomplete: it should be GPL or Artistic (the same as perl according to the README file) * Dist tag missing Other cosmetic changes included in the patch file. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Apache-LogRegex.spec.patch Type: text/x-patch Size: 921 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From fedora-extras-list at redhat.com Mon Jul 11 16:21:13 2005 From: fedora-extras-list at redhat.com (Jochen Schmitt) Date: Mon, 11 Jul 2005 18:21:13 +0200 Subject: New Package: git Message-ID: <20050711162113.GA30227@myhome> Hello, I have create an package for git, the lightwight SCM used by Linux Torwalds to develop the Linux kernel. SRPM: http://www.herr-schmitt.de/pub/git/git-0.99-1.src.rpm SPEC: http://www.herr-schmitt.de/pub/git/git.spec Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora-extras-list at redhat.com Mon Jul 11 16:25:48 2005 From: fedora-extras-list at redhat.com (Jochen Schmitt) Date: Mon, 11 Jul 2005 18:25:48 +0200 Subject: New Package: monotone Message-ID: <20050711162548.GB30227@myhome> Hello, I have create a package for monotone 0.20. Monotone is a distributed version control system. SRPM: http://www.herr-schmitt.de/pub/monotone/monotone-0.20-1.src.rpm SPEC: http://www.herr-schmitt.de/pub/monotone/monotone.spec Known Issues: On bug #162684 I have reported a issue on boost, which coused by a strange behaviour of gcc-4.0.1 with so called anoymous enums. you can compiled montone only, if you have build boost with the patch, I have posted on the bug report. Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jpo at di.uminho.pt Mon Jul 11 17:07:29 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 18:07:29 +0100 Subject: New Package: perl-Gnome2-Canvas In-Reply-To: <200507032229.35182.ghenry@suretecsystems.com> References: <200507032229.35182.ghenry@suretecsystems.com> Message-ID: <42D2A751.2050703@di.uminho.pt> Gavin, > SRPM: > http://www.perl.me.uk/downloads/modules/perl-Gnome2-Canvas-1.002-1.src.rpm > SPEC: http://www.perl.me.uk/downloads/modules/perl-Gnome2-Canvas.spec Needswork: * Lots of missing build requirements BuildRequires: perl(ExtUtils::Depends), perl(ExtUtils::PkgConfig) BuildRequires: perl(Glib), perl(Gtk2) BuildRequires: libgnomecanvas-devel >= 2.0.0 * Empty *.bs files should be removed in binary perl modules find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';' * Dist tag missing jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Gnome2-Canvas.spec.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Mon Jul 11 17:17:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 11 Jul 2005 13:17:40 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa7910507110917321e58b9@mail.gmail.com> Message-ID: <1121102260.7143.15.camel@cutter> On Mon, 2005-07-11 at 12:52 -0400, Greg DeKoenigsberg wrote: > My time is spread pretty thin -- so no, I'm not actually volunteering for > this duty. I just think it's a good idea. > > So what's it take to manage comps.xml? Jeremy? Seth? Anyone? > it takes a text editor. -sv From jpo at di.uminho.pt Mon Jul 11 17:16:51 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 18:16:51 +0100 Subject: New Package: perl-Gtk2-GladeXML In-Reply-To: <200507032242.41750.ghenry@suretecsystems.com> References: <200507032242.41750.ghenry@suretecsystems.com> Message-ID: <42D2A983.1040706@di.uminho.pt> Gavin, > SRPM: > http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML-1.005-1.src.rpm > SPEC: http://www.perl.me.uk/downloads/modules/perl-Gtk2-GladeXML.spec Needswork: * Lots of missing build requirements BuildRequires: perl(ExtUtils::Depends), perl(ExtUtils::PkgConfig) BuildRequires: perl(Glib), perl(Gtk2) BuildRequires: libglade2-devel >= 2.0.0 * Empty *.bs files should be removed in binary perl modules find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';' * Doc files shipped with +x permissions (rpm detects their requirements) Add the following line (or something similar) to the %prep section find examples -type f -exec chmod -x {} ';' * the changelog version doesn't match the package version * Dist tag missing jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Gtk2-GladeXML.spec.patch Type: text/x-patch Size: 1394 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From gdk at redhat.com Mon Jul 11 17:21:21 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 11 Jul 2005 13:21:21 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121102260.7143.15.camel@cutter> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa7910507110917321e58b9@mail.gmail.com> <1121102260.7143.15.camel@cutter> Message-ID: OK, text editor. Got it. What about from a testing perspective? What's the impact of completely hosing up the comps.xml file in the repo at fp.org? --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Mon, 11 Jul 2005, seth vidal wrote: > On Mon, 2005-07-11 at 12:52 -0400, Greg DeKoenigsberg wrote: > > My time is spread pretty thin -- so no, I'm not actually volunteering for > > this duty. I just think it's a good idea. > > > > So what's it take to manage comps.xml? Jeremy? Seth? Anyone? > > > > it takes a text editor. > > -sv > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jul 11 17:22:24 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 11 Jul 2005 19:22:24 +0200 Subject: New Package: git In-Reply-To: <20050711162113.GA30227@myhome> References: <20050711162113.GA30227@myhome> Message-ID: <20050711192224.1bd553c9@python2> Jochen Schmitt wrote : > I have create an package for git, the lightwight SCM used by Linux Torwalds > to develop the Linux kernel. > > SRPM: http://www.herr-schmitt.de/pub/git/git-0.99-1.src.rpm > SPEC: http://www.herr-schmitt.de/pub/git/git.spec Good : - Pretty much everything, builds and runs fine :-) Not so good : - The summary could be better - The optflags aren't used Attached is a patch to fix these two points, as well as some cosmetic things (why mix spaces and tabs on the same lines in the headers!?). If you apply at least the optflags change and change the summary to something a little more explicit which doesn't contain the name of the package, consider it APPROVED ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.35_FC3 Load : 0.30 0.50 0.51 -------------- next part -------------- A non-text attachment was scrubbed... Name: git.spec.patch Type: application/octet-stream Size: 1420 bytes Desc: not available URL: From skvidal at phy.duke.edu Mon Jul 11 17:25:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 11 Jul 2005 13:25:41 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa7910507110917321e58b9@mail.gmail.com> <1121102260.7143.15.camel@cutter> Message-ID: <1121102742.7143.19.camel@cutter> On Mon, 2005-07-11 at 13:21 -0400, Greg DeKoenigsberg wrote: > OK, text editor. Got it. What about from a testing perspective? What's > the impact of completely hosing up the comps.xml file in the repo at > fp.org? > people can't use the group commands. that's about it. -sv From jspaleta at gmail.com Mon Jul 11 17:26:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jul 2005 13:26:38 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: <604aa791050711102652edce83@mail.gmail.com> On 7/11/05, Chris Ricker wrote: > The other is how to include all the Fedora repositories. I realize that > livna is not / cannot officially be Fedora, for example, but it would > still be nice if this worked for them and others. How will 3rd-party > repositories extend? modify comps.xml in FC? or supplemental comps files > for each repository? comps file for each repo... just like Core and Extras have seperate comps files right now. 3rd parties can use their own comps and add items to groups defined in Core or Extras.. or they can add new groups. The comps aware tools in Core merge group definitions. -jef From katzj at redhat.com Mon Jul 11 17:31:45 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 Jul 2005 13:31:45 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121102742.7143.19.camel@cutter> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <604aa79105070907004bdda2a6@mail.gmail.com> <604aa7910507110917321e58b9@mail.gmail.com> <1121102260.7143.15.camel@cutter> <1121102742.7143.19.camel@cutter> Message-ID: <1121103105.3609.2.camel@bree.local.net> On Mon, 2005-07-11 at 13:25 -0400, seth vidal wrote: > On Mon, 2005-07-11 at 13:21 -0400, Greg DeKoenigsberg wrote: > > OK, text editor. Got it. What about from a testing perspective? What's > > the impact of completely hosing up the comps.xml file in the repo at > > fp.org? > people can't use the group commands. > > that's about it. Also, I have a (admittedly naive and simplistic) test to check that a comps file is mostly well-formed that could be added as a commit check. Also, probably we'll want a little bit of makefile magic to do the transformations so that we can incorporate translations at some point as well... Jeremy From jpo at di.uminho.pt Mon Jul 11 17:32:53 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Mon, 11 Jul 2005 18:32:53 +0100 Subject: New Package: Sprog In-Reply-To: <200507032222.08277.ghenry@suretecsystems.com> References: <200507022344.03123.ghenry@suretecsystems.com> <200507032222.08277.ghenry@suretecsystems.com> Message-ID: <42D2AD45.9050300@di.uminho.pt> Gavin, > > New release: > > SRPM: http://www.perl.me.uk/downloads/Sprog/Sprog-0.13-1.src.rpm > SPEC: http://www.perl.me.uk/downloads/Sprog/Sprog.spec * This is not a full review * Several problems: * you also need to package perl-Imager (http://search.cpan.org/dist/Imager/) Hint: lots of building requirements. * we need to wait for perl-Template-Toolkit (Ville and Spot are working on this ;)) * the build arch is wrong: this is a noarch package * ths %files section should be like this: %defattr(-,root,root,-) %{_bindir}/* %{perl_vendorlib}/Sprog* %{_mandir}/man3/*.3* * don't TABs in the specfile jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ed at eh3.com Mon Jul 11 17:37:24 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 11 Jul 2005 13:37:24 -0400 Subject: photran fortran dev module for eclipse In-Reply-To: <42D2A00F.9040807@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> Message-ID: <1121103445.13579.151.camel@ernie> On Mon, 2005-07-11 at 10:36 -0600, Orion Poplawski wrote: > Has anyone considered building a rpm for photran: > http://www.photran.org/ ? Are there other fortran modules for eclipse > under development that are "better"? I was going to start trying to > package it for Extras, but wanted to check with others first. Hi Orion, Thanks for the link--I wasn't aware that it existed! Will give it a try and see how it compares with emacs Fortran mode. ;-) Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From jpo at di.uminho.pt Mon Jul 11 17:56:32 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 18:56:32 +0100 Subject: Approved - perl-DBD-SQLite (external library vs self-contained) In-Reply-To: <20050708131815.0acfac43@python2> References: <1118516616.2667.83.camel@laptop.mpeters.local> <1118516783.2457.9.camel@cutter> <1118517992.2667.88.camel@laptop.mpeters.local> <20050708131815.0acfac43@python2> Message-ID: <42D2B2D0.9020500@di.uminho.pt> Matthias Saou wrote: > Michael A. Peters wrote : > > >>>wait, what??? >>> >>>it includes a duplicate copy of SQLite? >>> >>>That's kinda crack, isn't it? >> >>Yes. And the wiki about fc5 says Fedora wants to reduce that kind of >>thing. >> >>This summer I intend to try and patch the makefile so that it has the >>option of using system sqlite as that is better on the security end >>(regarding flaws in sqlite) and will try to get it upstream. > > > The same is true with the PHP sqlite module (both the "old" one, included > in PHP sources of 5.x, and the "new" one that uses PDO) :-( I really > wonder why authors choose to go in this direction... > > If anyone wants to take a go at ripping out the sqlite sources from both > the PHP and perl modules, and have them link against shared libraries > instead, that would be great! perl-DBD-SQLite --------------- The new version that is available on CPAN already supports the external SQLite library. (If it finds sqlite >= 3.2.1, it uses it; otherwise it builds itself self-contained). I'm still waiting for the rawhide SQLite update in order to commit the new perl-DBD-SQLite to extras (devel branch). DBD::SQLite http://search.cpan.org/dist/DBD-SQLite/ http://search.cpan.org/src/MSERGEANT/DBD-SQLite-1.09/Changes Rawhide: sqlite update request https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161840 jpo PS - Michael: Do you still want to maintain it? -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From overholt at redhat.com Mon Jul 11 17:58:52 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Jul 2005 13:58:52 -0400 Subject: [fedora-java] photran fortran dev module for eclipse In-Reply-To: <42D2A00F.9040807@cora.nwra.com> References: <42D2A00F.9040807@cora.nwra.com> Message-ID: <1121104732.10147.3.camel@tofu.toronto.redhat.com> On Mon, 2005-11-07 at 10:36 -0600, Orion Poplawski wrote: > Has anyone considered building a rpm for photran: > http://www.photran.org/ ? Are there other fortran modules for eclipse > under development that are "better"? I was going to start trying to > package it for Extras, but wanted to check with others first. I haven't tried myself and I don't know of anyone that has. I'm also not very familiar with it, but I *think* Photran is the Fortran plug-in that I've heard of before. Having this in Extras would be great! Thanks, Andrew From ville.skytta at iki.fi Mon Jul 11 18:40:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Jul 2005 21:40:32 +0300 Subject: Review: perl-Template-Toolkit In-Reply-To: <1120933208.2892.148.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120933208.2892.148.camel@localhost.localdomain> Message-ID: <1121107232.2892.312.camel@localhost.localdomain> On Sat, 2005-07-09 at 21:20 +0300, Ville Skytt? wrote: > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > perl-Template-Toolkit: > > Template processing system > > I have had a package of this too for some time, so I merged it with > yours, results attached. Ok, approval sent to -commits. Thanks. One minor note about the package currently in CVS: perl(Tie::DBI) is not a build dependency because the database tests are explicitly disabled. From jpo at di.uminho.pt Mon Jul 11 18:46:13 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 19:46:13 +0100 Subject: Review: perl-CGI-Simple In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <42D2BE75.5010207@di.uminho.pt> Tom, > perl-CGI-Simple: > Simple totally OO CGI interface that is CGI.pm compliant Needswork: * wrong URL (case-sensitive) * wrong permissions in *.pm and doc files (+x ?) * one documentation files missing (cgi-simple_vs_cgi-pm.html) (the other html files in the htnl directory are the man pages) Other notes: * the license appears to be correct (the CGI::Simple pod page only says "Artitisc" but several other files mention "as Perl itself", which implies GPL or Artistic) jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-CGI-Simple.spec.patch Type: text/x-patch Size: 907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Mon Jul 11 19:03:02 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 20:03:02 +0100 Subject: Review: perl-Exporter-Lite In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <42D2C266.6080202@di.uminho.pt> Tom 'spot' Callaway wrote: > All of the specs and SRPMs can be found in here: > http://auroralinux.org/people/spot/review/Maypole/ > ... > perl-Exporter-Lite: > Lightweight exporting of variables Notes: * the changelog release doesn't match the package release * the license can't be confirmed (GPL or Artistic). The author being who he is, it will most likely be "GPL or Artistic" (same as Perl itself) but for the moment we should use distributable. Everything else looks good. jpo PS - License information request can be placed here http://rt.cpan.org/NoAuth/Bugs.html?Dist=Exporter-Lite (last time I did it, it worked) -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From lmacken at redhat.com Mon Jul 11 18:56:10 2005 From: lmacken at redhat.com (Luke Macken) Date: Mon, 11 Jul 2005 14:56:10 -0400 Subject: Request for Review: nethack In-Reply-To: <1121096783.2892.258.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> <20050711123654.GA6289@tomservo.boston.redhat.com> <1121094015.2892.221.camel@localhost.localdomain> <20050711150709.GB6416@tomservo.boston.redhat.com> <1121096783.2892.258.camel@localhost.localdomain> Message-ID: <20050711185610.GA6774@tomservo.boston.redhat.com> On Mon, Jul 11, 2005 at 06:46:23PM +0300, Ville Skytt? wrote: | > I just not seeing how we | > benefit from restricting Fedora users to install *extremely* unstable | > graphical versions of a text based game. | | Where can I read more about this extreme unstability? https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00535.html The game does not idle very well, and is pretty much unplayable at 1024x768 if you have any sort of desktop panel (i haven't looked into changing the res of the game, but it could be possible). | This thread already contains suggestions how to make the GUI version | packaging more friendly for the tty fans, and addresses. And FWIW, I'm | definitely one, I don't personally really care much at all about any of | the the GUIs. Practically speaking, that means if the vanilla NetHack | enters Extras, the GUI version will need a new maintainer. While I'd be | happy to let go of it, end users will lose unless someone else steps up. | | You seem to have strong opinions about this and I guess you'll pursue | packaging the vanilla one anyway, so: I'd suggest at least taking a look | at the nethack-falconseye specfile, the package is in a pretty good | shape at the moment IIRC. Also, suggestions how to handle the | inevitable conflicts between the "vanilla" and the GUI one are welcome, | and IMO need to be decided/addressed if and before the two are both in | Extras. I feel strongly about having an up-to-date version in the tree (mostly because a bug in 3.4.1 prevented me from ascending in the past). I guess my argument is that I think we should give users the choice of any nethack frontend that anyone is willing to package for Extras and not restrict them to having to install something graphical if they aren't even going to use it. luke From jwboyer at jdub.homelinux.org Mon Jul 11 19:10:18 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 11 Jul 2005 14:10:18 -0500 (CDT) Subject: New Package: git In-Reply-To: <20050711162113.GA30227@myhome> References: <20050711162113.GA30227@myhome> Message-ID: <52934.129.42.161.36.1121109018.squirrel@jdub.homelinux.org> > Hello, > > I have create an package for git, the lightwight SCM used by Linux > Torwalds > to develop the Linux kernel. > > SRPM: http://www.herr-schmitt.de/pub/git/git-0.99-1.src.rpm > SPEC: http://www.herr-schmitt.de/pub/git/git.spec That version just showed up yesterday and hasn't been "officially" released yet, right? josh From notting at redhat.com Mon Jul 11 19:07:59 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jul 2005 15:07:59 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121103105.3609.2.camel@bree.local.net> References: <604aa79105070907004bdda2a6@mail.gmail.com> <604aa7910507110917321e58b9@mail.gmail.com> <1121102260.7143.15.camel@cutter> <1121102742.7143.19.camel@cutter> <1121103105.3609.2.camel@bree.local.net> Message-ID: <20050711190759.GA14866@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > people can't use the group commands. > > > > that's about it. > > Also, I have a (admittedly naive and simplistic) test to check that a > comps file is mostly well-formed that could be added as a commit check. > > Also, probably we'll want a little bit of makefile magic to do the > transformations so that we can incorporate translations at some point as > well... The current Extras comps file has merged-once-static translations. I'd suggest just moving all the fedora comps and associated translations to cvs.fedora. Bill From tcallawa at redhat.com Mon Jul 11 19:18:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Jul 2005 14:18:53 -0500 Subject: Review: perl-Template-Toolkit In-Reply-To: <1121107232.2892.312.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <1120933208.2892.148.camel@localhost.localdomain> <1121107232.2892.312.camel@localhost.localdomain> Message-ID: <1121109533.22400.151.camel@localhost.localdomain> On Mon, 2005-07-11 at 21:40 +0300, Ville Skytt? wrote: > On Sat, 2005-07-09 at 21:20 +0300, Ville Skytt? wrote: > > On Thu, 2005-07-07 at 15:33 -0500, Tom 'spot' Callaway wrote: > > > > > perl-Template-Toolkit: > > > Template processing system > > > > I have had a package of this too for some time, so I merged it with > > yours, results attached. > > Ok, approval sent to -commits. Thanks. > > One minor note about the package currently in CVS: perl(Tie::DBI) is not > a build dependency because the database tests are explicitly disabled. OK, that makes sense. I'll pull it out. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jpo at di.uminho.pt Mon Jul 11 19:20:14 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 20:20:14 +0100 Subject: Review: perl-SQL-Abstract In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <42D2C66E.4060902@di.uminho.pt> Tom 'spot' Callaway wrote: > > All of the specs and SRPMs can be found in here: > http://auroralinux.org/people/spot/review/Maypole/ > ... > perl-SQL-Abstract: > Generate SQL from Perl data structures Note: * the changelog release doesn't match the package release Everything else looks good. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From chrisw at osdl.org Mon Jul 11 19:35:34 2005 From: chrisw at osdl.org (Chris Wright) Date: Mon, 11 Jul 2005 12:35:34 -0700 Subject: Request for review: cogito In-Reply-To: <20050710193337.F078E1809FD@magilla.sf.frob.com> References: <1121023341.22400.60.camel@localhost.localdomain> <20050710193337.F078E1809FD@magilla.sf.frob.com> Message-ID: <20050711193534.GM19052@shell0.pdx.osdl.net> * Roland McGrath (roland at redhat.com) wrote: > > Neil Horman, Chris Wright, and now you have all expressed interest in > > maintaining cogito. Previous requests were halted, due to concerns about > > the maturity level of the software. I suspect at this point its fine > > (and there is obviously demand). The three of you should figure out who > > will own this, then I'll be happy to review the end package. > > I have no great desire to do it, just a desire to have it there and a > willingness to help make it happen. No matter how immature it is, we are > using it today (and there is nothing very mature available to deal with > Linus's repositories). So might as well have it easy to install. > > If we can't put immature but packageable and usable software into Extras, > then we'll just have to have yet another infrastructure like Extras for us > to collaborate on the Fedora-standard nonstandard stuff. I don't see why > anyone would want that. I've added rpm build to core git now as well. As soon as cogito is just scripts on top of core git, then it should be a no-brainer to include both where cogito has intstall dependency on git. Could go earlier, and if so, I need to remove one bit from cogito spec file (the obsoletes line). Current cogito srpm is up on kernel.org at: http://www.kernel.org/pub/software/scm/cogito/RPMS/cogito-0.12-1.src.rpm That RPMS dir should also work as a yum repo. thanks, -chris From jpo at di.uminho.pt Mon Jul 11 19:46:22 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 11 Jul 2005 20:46:22 +0100 Subject: Review: perl-Test-MockModule In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <42D2CC8E.3040801@di.uminho.pt> Tom 'spot' Callaway wrote: > ... > All of the specs and SRPMs can be found in here: > http://auroralinux.org/people/spot/review/Maypole/ > ... > perl-Test-MockModule: > Override subroutines in a module for unit testing Needwork: * missing build requirements. For better test suite coverage include the following line: BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage) Everything else looks good. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Jochen at herr-schmitt.de Mon Jul 11 20:02:19 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 11 Jul 2005 22:02:19 +0200 Subject: Request for review: cogito In-Reply-To: <20050711193534.GM19052@shell0.pdx.osdl.net> References: <1121023341.22400.60.camel@localhost.localdomain> <20050710193337.F078E1809FD@magilla.sf.frob.com> <20050711193534.GM19052@shell0.pdx.osdl.net> Message-ID: <0ML29c-1Ds4U93Xck-0007ph@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 11 Jul 2005 12:35:34 -0700, you wrote: >I've added rpm build to core git now as well. As soon as cogito is just >scripts on top of core git, then it should be a no-brainer to include >both where cogito has intstall dependency on git. Could go earlier, and >if so, I need to remove one bit from cogito spec file (the obsoletes >line). I have started the introduction of git into Fedora Extras, so I think it's not a good idea to include git core into your package. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQtLQXU9gByurcX4MEQI7SgCgyCFgoG9CEGwZW5qonXBeTSQQ+CgAoIWJ epy4R1l2OZOFiV8QmBtF0FLG =gNau -----END PGP SIGNATURE----- From jwboyer at jdub.homelinux.org Mon Jul 11 20:10:31 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 11 Jul 2005 15:10:31 -0500 (CDT) Subject: Request for review: cogito In-Reply-To: <0ML29c-1Ds4U93Xck-0007ph@mrelayeu.kundenserver.de> References: <1121023341.22400.60.camel@localhost.localdomain> <20050710193337.F078E1809FD@magilla.sf.frob.com> <20050711193534.GM19052@shell0.pdx.osdl.net> <0ML29c-1Ds4U93Xck-0007ph@mrelayeu.kundenserver.de> Message-ID: <53495.129.42.161.36.1121112631.squirrel@jdub.homelinux.org> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 11 Jul 2005 12:35:34 -0700, you wrote: > >>I've added rpm build to core git now as well. As soon as cogito is just >>scripts on top of core git, then it should be a no-brainer to include >>both where cogito has intstall dependency on git. Could go earlier, and >>if so, I need to remove one bit from cogito spec file (the obsoletes >>line). > > I have started the introduction of git into Fedora Extras, so I > think it's not a good idea to include git core into your package. Yes, but upstream cogito does this. Until the upstream release doesn't include git the RPM will as well. So the obsoletes would still be required if we are going to have both cogito and git packages at this point. The other alternative is to wait on both until upstream cogito no longer includes core git. josh From Jochen at herr-schmitt.de Mon Jul 11 20:11:04 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 11 Jul 2005 22:11:04 +0200 Subject: New Package: git In-Reply-To: <52934.129.42.161.36.1121109018.squirrel@jdub.homelinux.org> References: <20050711162113.GA30227@myhome> <52934.129.42.161.36.1121109018.squirrel@jdub.homelinux.org> Message-ID: <0MKwtQ-1Ds4cL1Og0-00020u@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 11 Jul 2005 14:10:18 -0500 (CDT), you wrote: >> Hello, >> >> I have create an package for git, the lightwight SCM used by Linux >> Torwalds >> to develop the Linux kernel. >> >> SRPM: http://www.herr-schmitt.de/pub/git/git-0.99-1.src.rpm >> SPEC: http://www.herr-schmitt.de/pub/git/git.spec > >That version just showed up yesterday and hasn't been "officially" >released yet, right? Can you tell my your source from which you known, that this is not a official released version. The URL in the SPEC file show on http://www.kernel.org/pub/software/scm/git which contains a directory of the http server. I thought, the URL tag should shows on a official project page. But becouse I saw only the cirectory, I assumed, that no one exists. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQtLSWE9gByurcX4MEQJcMgCffdEXL/TFhhX25fbNPy2IvO1hQG8AoMGx NVmJg2yzyn58dTuotD0MlMiI =x1J3 -----END PGP SIGNATURE----- From jwboyer at jdub.homelinux.org Mon Jul 11 20:30:21 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 11 Jul 2005 15:30:21 -0500 (CDT) Subject: New Package: git In-Reply-To: <0MKwtQ-1Ds4cL1Og0-00020u@mrelayeu.kundenserver.de> References: <20050711162113.GA30227@myhome> <52934.129.42.161.36.1121109018.squirrel@jdub.homelinux.org> <0MKwtQ-1Ds4cL1Og0-00020u@mrelayeu.kundenserver.de> Message-ID: <41782.129.42.161.36.1121113821.squirrel@jdub.homelinux.org> > -----BEGIN PGP SIGNED MESSAGE----- >>> >>> SRPM: http://www.herr-schmitt.de/pub/git/git-0.99-1.src.rpm >>> SPEC: http://www.herr-schmitt.de/pub/git/git.spec >> >>That version just showed up yesterday and hasn't been "officially" >>released yet, right? > > Can you tell my your source from which you known, that this is > not a official released version. There hasn't been an announce message on the git mailing list, and there is no tarball. Those RPMs are trial RPMs, as specified in this thread: http://marc.theaimsgroup.com/?l=git&m=112104471808807&w=2 Plus, those were just built yesterday. From the same thread as above, it almost seems as if Linus is trying to pave the way for cogito to be separated. Perhaps we should have some patience and wait for a few more days to see what develops. josh From ivazquez at ivazquez.net Mon Jul 11 23:17:36 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Jul 2005 19:17:36 -0400 Subject: Request for Review: xmlstartlet Message-ID: <1121123856.4423.8.camel@ignacio.lan> xmlstarlet: A set of command line utilities for XML XMLStarlet is a set of command line utilities (tools) which can be used to transform, query, validate, and edit XML documents and files using simple set of shell commands in similar way it is done for plain text files using UNIX grep, sed, awk, diff, patch, join, etc commands. This set of command line utilities can be used by those who deal with many XML documents on UNIX shell command prompt as well as for automated XML processing with shell scripts. http://fedora.ivazquez.net/files/extras/xmlstarlet.spec http://fedora.ivazquez.net/files/extras/xmlstarlet-1.0.1-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mfleming at enlartenment.com Mon Jul 11 23:43:01 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Tue, 12 Jul 2005 09:43:01 +1000 Subject: Request for review / approval: mod_security. In-Reply-To: <200507092119.j69LJlrP014361@mail.linux-kernel.at> References: <20050709212706.0e6bdb21.mfleming@enlartenment.com> <200507092119.j69LJlrP014361@mail.linux-kernel.at> Message-ID: <20050711234301.GA4689@enlartenment.com> On Sat, Jul 09, 2005 at 11:20:12PM +0200, Oliver Falk waffled thusly: > > On Sat, 09 Jul 2005 13:26:11 +0300. Ville Skytt? waffled thusly: > > > > > On Sat, 2005-07-09 at 19:48 +1000, Michael Fleming wrote: > > > > > > > > > Updated SRPM > > > > > > http://www.enlartenment.com/extras/mod_security/mod_security-1 > > > > > > .8.7-3.src.rpm Any more comments on this? Perhaps any interesting or useful rules for common apps I'm not aware of (I think I've covered the usual suspects). Official approval for a build and cvssync perhaps? ;-) Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From alex at dalloz.de Mon Jul 11 23:52:19 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Tue, 12 Jul 2005 01:52:19 +0200 Subject: Request for review: keychain Message-ID: <1121125939.1574.170.camel@serendipity.dogma.lan> keychain: agent manager for OpenSSH, ssh.com, Sun SSH, and GnuPG Keychain is a manager for OpenSSH, ssh.com, Sun SSH and GnuPG agents. It acts as a front-end to the agents, allowing you to easily have one long-running agent process per system, rather than per login session. This dramatically reduces the number of times you need to enter your passphrase from once per new login session to once every time your local machine is rebooted. I promote keychain as a very handy tool which offers the nice possibility to use passphrase protected keys through cronjobs, i.e. for scheduled, unattended backup jobs. http://www.gentoo.org/proj/en/keychain/ keychain is made made by Aron Griffis from gentoo.org. He even offers (s)rpms. I just did small changes to the .spec file. http://www.uni-x.org/keychain.spec http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ed at eh3.com Tue Jul 12 02:10:35 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 11 Jul 2005 22:10:35 -0400 Subject: Request for review: keychain In-Reply-To: <1121125939.1574.170.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> Message-ID: <1121134236.26750.74.camel@ernie> On Tue, 2005-07-12 at 01:52 +0200, Alexander Dalloz wrote: > keychain: agent manager for OpenSSH, ssh.com, Sun SSH, and GnuPG > http://www.uni-x.org/keychain.spec > http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm Hi Alexander, Hey, thats funny! I've been referring people to those well-written IBM developerWorks articles on SSH: http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ that are referenced from the main keychain web site but I never actually took the time to learn about or use keychain itself. I just use ssh-add and ssh-agent. Silly me! So heres a quick review of keychain which mostly looks good: please fix: - rpmlint complains: W: keychain summary-not-capitalized agent manager ... - BuildRoot should be: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - please add dist to version: 2.5.4.1%{?dist} good: - names OK - spec mostly OK (except above) -- *very* simple! - src matches upstream - license OK - seems to build, install, and work on FC3 - cleans OK - perms OK - code not content OK And, if possible, it would be nice if we could get a second opinion on the security implications of the actual "keychain" shell script. I'm *no* security guru and maybe someone more knowledgeable could step in and say the script looks OK. Or that its probably OK since its widely used and widely reviewed...? Or, is that just too much to ask for as part of the package review process? Ed -- who doesn't want to become known as "that moron who said it was just dandy to include a security nightmare in Extras" ;-) -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From chris at chrisgrau.com Tue Jul 12 02:41:56 2005 From: chris at chrisgrau.com (Chris Grau) Date: Mon, 11 Jul 2005 19:41:56 -0700 Subject: Request for review: keychain In-Reply-To: <1121134236.26750.74.camel@ernie> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> Message-ID: <20050712024156.GA19809@chrisgrau.com> On Mon, Jul 11, 2005 at 10:10:35PM -0400, Ed Hill wrote: > On Tue, 2005-07-12 at 01:52 +0200, Alexander Dalloz wrote: > > keychain: agent manager for OpenSSH, ssh.com, Sun SSH, and GnuPG > > > http://www.uni-x.org/keychain.spec > > http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm > > > Hi Alexander, > > Hey, thats funny! I've been referring people to those well-written IBM > developerWorks articles on SSH: > > http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ > > that are referenced from the main keychain web site but I never actually > took the time to learn about or use keychain itself. I just use ssh-add > and ssh-agent. Silly me! > > So heres a quick review of keychain which mostly looks good: > > please fix: > - rpmlint complains: > W: keychain summary-not-capitalized agent manager ... > - BuildRoot should be: > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > - please add dist to version: 2.5.4.1%{?dist} That shouldn't be added to revision rather than version? > good: > - names OK > - spec mostly OK (except above) -- *very* simple! > - src matches upstream > - license OK > - seems to build, install, and work on FC3 > - cleans OK > - perms OK > - code not content OK > > And, if possible, it would be nice if we could get a second opinion on > the security implications of the actual "keychain" shell script. I'm > *no* security guru and maybe someone more knowledgeable could step in > and say the script looks OK. Or that its probably OK since its widely > used and widely reviewed...? > > Or, is that just too much to ask for as part of the package review > process? The script is pretty long, but I've skimmed it in the past. I'm not really an expert, but it's just a fancy wrapper around ssh-agent and ssh-add, so the security implications are more or less passed on to those programs. > Ed -- who doesn't want to become known as "that moron who said it was > just dandy to include a security nightmare in Extras" ;-) -chris -- who will probably become known as "that moron who seconded Ed's dandy opinion" From ivazquez at ivazquez.net Tue Jul 12 02:49:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Jul 2005 22:49:44 -0400 Subject: Request for review: keychain In-Reply-To: <1121125939.1574.170.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> Message-ID: <1121136584.4423.17.camel@ignacio.lan> On Tue, 2005-07-12 at 01:52 +0200, Alexander Dalloz wrote: > keychain: agent manager for OpenSSH, ssh.com, Sun SSH, and GnuPG > > Keychain is a manager for OpenSSH, ssh.com, Sun SSH and GnuPG agents. It > acts as a front-end to the agents, allowing you to easily have one > long-running agent process per system, rather than per login session. > This dramatically reduces the number of times you need to enter your > passphrase from once per new login session to once every time your local > machine is rebooted. > > I promote keychain as a very handy tool which offers the nice > possibility to use passphrase protected keys through cronjobs, i.e. for > scheduled, unattended backup jobs. > > http://www.gentoo.org/proj/en/keychain/ Would this warrant an entry in /etc/profile.d to load it on login? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 alex at dalloz.de Tue Jul 12 03:31:22 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Tue, 12 Jul 2005 05:31:22 +0200 Subject: Request for review: keychain In-Reply-To: <1121134236.26750.74.camel@ernie> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> Message-ID: <1121139082.1574.182.camel@serendipity.dogma.lan> Am Di, den 12.07.2005 schrieb Ed Hill um 4:10: > Hi Alexander, Hi Ed! Thanks for your review and comments. > Hey, thats funny! I've been referring people to those well-written IBM > developerWorks articles on SSH: > > http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ The article is a bit older, unfortunately, and things changed a bit with keychain since its publishing. > that are referenced from the main keychain web site but I never actually > took the time to learn about or use keychain itself. I just use ssh-add > and ssh-agent. Silly me! keychain does not obsoletes both tools - it just makes their usage more comfortable. I am sure you know that, just want to point that out again for other readers. > So heres a quick review of keychain which mostly looks good: > > please fix: > - rpmlint complains: > W: keychain summary-not-capitalized agent manager ... Changed. > - BuildRoot should be: > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > - please add dist to version: 2.5.4.1%{?dist} From guideline reading I found that the dist tag isn't mandatory and as it is a noarch package I thought it would have been ok to omit the tag. Changed it though. Both the .spec and the src.rpm are renewed and available at: http://www.uni-x.org/keychain.spec http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm > Ed -- who doesn't want to become known as "that moron who said it was > just dandy to include a security nightmare in Extras" ;-) Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From alex at dalloz.de Tue Jul 12 03:38:33 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Tue, 12 Jul 2005 05:38:33 +0200 Subject: Request for review: keychain In-Reply-To: <1121136584.4423.17.camel@ignacio.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> Message-ID: <1121139513.1574.191.camel@serendipity.dogma.lan> Am Di, den 12.07.2005 schrieb Ignacio Vazquez-Abrams um 4:49: > > I promote keychain as a very handy tool which offers the nice > > possibility to use passphrase protected keys through cronjobs, i.e. for > > scheduled, unattended backup jobs. > > > > http://www.gentoo.org/proj/en/keychain/ > > Would this warrant an entry in /etc/profile.d to load it on login? You are right, keychain does not get active just by installation. "man 1 keychain" contains examples on how to use it in profile or rc files with different shells. To give an example, this is what I use with bash: $ cat ~/.bash_profile # .bash_profile # start keychain and point it to the private keys # that we'd like to cache KEY="`ls ${HOME}/.ssh/*dsa`" /usr/bin/keychain ${KEY} if [ -f ${HOME}/.keychain/${HOSTNAME}-sh ]; then . ${HOME}/.keychain/${HOSTNAME}-sh > /dev/null else echo "there is a problem with keychain" fi Logging in as the user I am asked for the passphrase of each DSA key. I don't think such an activation should be done for all users by rpm package installation (if that is the question behind your comment). Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From alex at dalloz.de Tue Jul 12 03:46:11 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Tue, 12 Jul 2005 05:46:11 +0200 Subject: Request for review: gyrus Message-ID: <1121139971.1574.200.camel@serendipity.dogma.lan> gyrus: GNOME Cyrus-IMAPd Administrator gyrus is a GNOME based tool for the administration of mailboxes in Cyrus-IMAPd servers. It allows to control user quotas, create and remove mailboxes, and to manipulate the Access Control List for each mailbox. http://gyrus.gnome.cl/ At the moment gyrus isn't yet the tool it promises from summary. It may though be a help. Be touch to criticize this packaging: http://www.uni-x.org/gyrus.spec http://www.uni-x.org/gyrus-0.3.3-1.src.rpm Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From chip.turner at gmail.com Tue Jul 12 03:54:22 2005 From: chip.turner at gmail.com (Chip Turner) Date: Mon, 11 Jul 2005 20:54:22 -0700 Subject: Request for review: keychain In-Reply-To: <1121139513.1574.191.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> Message-ID: <3ab624bd050711205432e6650e@mail.gmail.com> It would be nicer to have some sort of opt-in, perhaps in the form of ~/.keychainrc, which, if present, causes it to be source'd and then, if set, use an environment variable KEYS to list the keys the user wants, otherwise default to id_dsa. This way a user just specifies their keys that feed the command line (and perhaps other command line options such as timeout). Chip On 7/11/05, Alexander Dalloz wrote: > Am Di, den 12.07.2005 schrieb Ignacio Vazquez-Abrams um 4:49: > > > > I promote keychain as a very handy tool which offers the nice > > > possibility to use passphrase protected keys through cronjobs, i.e. for > > > scheduled, unattended backup jobs. > > > > > > http://www.gentoo.org/proj/en/keychain/ > > > > Would this warrant an entry in /etc/profile.d to load it on login? > > You are right, keychain does not get active just by installation. "man 1 > keychain" contains examples on how to use it in profile or rc files with > different shells. To give an example, this is what I use with bash: > > $ cat ~/.bash_profile > > # .bash_profile > > # start keychain and point it to the private keys > # that we'd like to cache > KEY="`ls ${HOME}/.ssh/*dsa`" > /usr/bin/keychain ${KEY} > if [ -f ${HOME}/.keychain/${HOSTNAME}-sh ]; then > . ${HOME}/.keychain/${HOSTNAME}-sh > /dev/null > else > echo "there is a problem with keychain" > fi > > Logging in as the user I am asked for the passphrase of each DSA key. I > don't think such an activation should be done for all users by rpm > package installation (if that is the question behind your comment). > > Alexander > > > -- > > 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) > Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 > > > > BodyID:61891864.2.n.logpart (stored separately) > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > -- Chip Turner chip.turner at gmail.com From ed at eh3.com Tue Jul 12 04:11:47 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 12 Jul 2005 00:11:47 -0400 Subject: Request for review: keychain In-Reply-To: <3ab624bd050711205432e6650e@mail.gmail.com> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> Message-ID: <1121141507.26750.89.camel@ernie> On Mon, 2005-07-11 at 20:54 -0700, Chip Turner wrote: > It would be nicer to have some sort of opt-in, perhaps in the form of > ~/.keychainrc, which, if present, causes it to be source'd and then, > if set, use an environment variable KEYS to list the keys the user > wants, otherwise default to id_dsa. This way a user just specifies > their keys that feed the command line (and perhaps other command line > options such as timeout). +1 -- the above opt-in and the idea that a user can specify the keys or a glob (filename matching pattern) is cool And perhaps call it KEYCHAIN_KEYS since KEYS is pretty generic? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From chip.turner at gmail.com Tue Jul 12 04:13:36 2005 From: chip.turner at gmail.com (Chip Turner) Date: Mon, 11 Jul 2005 21:13:36 -0700 Subject: Request for review: keychain In-Reply-To: <1121141507.26750.89.camel@ernie> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> <1121141507.26750.89.camel@ernie> Message-ID: <3ab624bd05071121131fae0a5d@mail.gmail.com> You want to be careful about the globbing because id_dsa and id_dsa.pub, etc, but yeah, KEYS is a horribly generic name. I suck at naming :) Chip On 7/11/05, Ed Hill wrote: > On Mon, 2005-07-11 at 20:54 -0700, Chip Turner wrote: > > It would be nicer to have some sort of opt-in, perhaps in the form of > > ~/.keychainrc, which, if present, causes it to be source'd and then, > > if set, use an environment variable KEYS to list the keys the user > > wants, otherwise default to id_dsa. This way a user just specifies > > their keys that feed the command line (and perhaps other command line > > options such as timeout). > > > +1 -- the above opt-in and the idea that a user can specify the keys or > a glob (filename matching pattern) is cool > > And perhaps call it KEYCHAIN_KEYS since KEYS is pretty generic? > > Ed > > -- > Edward H. Hill III, PhD > office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. > Cambridge, MA 02139-4307 > emails: eh3 at mit.edu ed at eh3.com > URLs: http://web.mit.edu/eh3/ http://eh3.com/ > phone: 617-253-0098 > fax: 617-253-4464 > > -- Chip Turner chip.turner at gmail.com From skvidal at phy.duke.edu Tue Jul 12 05:51:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Jul 2005 01:51:54 -0400 Subject: buildsys update information Message-ID: <1121147515.10435.35.camel@cutter> Hi Everyone, Wanted to give you a heads up on the build system status. Right now it is still down. We've run into a snag where it seems like python on x86_64 or ppc on FC4 is not playing nicely with the threading and pyOpenSSL use by the buildsys code. I'm going to testing this theory on a 'spare' machine tomorrow and if it works out punting the build system boxes back to FC3 or RHEL4 for our use. After that it should be all gravy and sunshine.(hah hah) Sorry for the delay in getting things back up and running and please bear with us. When the new system comes up you, as developers and submitters of jobs, will have to add a couple of new files to your homedirs so you can submit jobs. We'll be writing up where to get these files and what to do with them once we have everything online. Again, sorry for the hassle. It'll all be over soon and then you'll have a whole new set of things to complain about! :) -sv From oliver at linux-kernel.at Tue Jul 12 07:35:41 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 12 Jul 2005 09:35:41 +0200 Subject: APPROVED: perl-Template-Toolkit In-Reply-To: <1121107067.2892.308.camel@localhost.localdomain> References: <1121107067.2892.308.camel@localhost.localdomain> Message-ID: <42D372CD.1080001@linux-kernel.at> On 07/11/2005 08:37 PM, Ville Skytt? wrote: > The Template Toolkit is a collection of modules which implement a > fast, flexible, powerful and extensible template processing system. > > Reviewer: Ville Skytt? > Maintainer: Tom Callaway Will it be available for FC[1,2,3,4]? Best, Oliver From oliver at linux-kernel.at Tue Jul 12 07:44:32 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 12 Jul 2005 09:44:32 +0200 Subject: Request for review / approval: mod_security. In-Reply-To: <20050711234301.GA4689@enlartenment.com> References: <20050709212706.0e6bdb21.mfleming@enlartenment.com> <200507092119.j69LJlrP014361@mail.linux-kernel.at> <20050711234301.GA4689@enlartenment.com> Message-ID: <42D374E0.8090508@linux-kernel.at> On 07/12/2005 01:43 AM, Michael Fleming wrote: > On Sat, Jul 09, 2005 at 11:20:12PM +0200, Oliver Falk waffled thusly: > >>>On Sat, 09 Jul 2005 13:26:11 +0300. Ville Skytt? waffled thusly: >>> >>> >>>>On Sat, 2005-07-09 at 19:48 +1000, Michael Fleming wrote: >>>> >>>> >>>>>>>Updated SRPM >>>>>>>http://www.enlartenment.com/extras/mod_security/mod_security-1 >>>>>>>.8.7-3.src.rpm > > > > > Any more comments on this? Perhaps any interesting or useful rules for > common apps I'm not aware of (I think I've covered the usual suspects). > Official approval for a build and cvssync perhaps? ;-) None for my side. Commit it, check the owners.list, check Bugzilla, check if you need any more branches, wait 'til the new buildsys is ready to use and fire a build request :-) Best, Oliver From oliver at linux-kernel.at Tue Jul 12 08:00:19 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 12 Jul 2005 10:00:19 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121100153.22665.295.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> Message-ID: <42D37893.9030902@linux-kernel.at> On 07/11/2005 06:42 PM, Alexander Dalloz wrote: > Hello fellows! > > I kindly request for a sponsorship and like to introduce myself with a > small package contribution, called pam_abl. > > pam_abl provides auto blacklisting of hosts and users responsible for > repeated failed authentication attempts. Generally configured so that > blacklisted users still see normal login prompts but are guaranteed to > fail to authenticate. A command line tool allows to query or purge the > databases used by the pam_abl module. > > The home of the software is: > > http://www.hexten.net/sw/pam_abl/ > > In my humble opinion this PAM module is useful in time when many of use > get hit by massive SSH connection attempts, even dictionary attacks. It > has some more flexibility (wider range of configuration) above pam_tally > (faillog). > > SRC.RPM and SPEC file can be taken for a review from: > > http://www.uni-x.org/pam_abl-0.2.2-20050110.src.rpm > http://www.uni-x.org/pam_abl.spec > > I hope I can come up with a few more packages for Extras soon. > > Alexander > > (can be reached on freenode as "Zerberus") Tried this, but get the following, if I enable pam_abl in system-auth: Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: pam_sm_open_session Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: pam_sm_close_session :-/ Specfile: * Release should be 1%{?dist} * You should not make * rpmlint complains: W: pam_abl non-standard-group Base E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so * Do not add an 'install howto' in the description. So far... For sure there are other things as well, but I had no closer look at the pkg, since it doesn't work here... :-/ Best, Oliver From rc040203 at freenet.de Tue Jul 12 08:16:57 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 Jul 2005 10:16:57 +0200 Subject: Request for review: gyrus In-Reply-To: <1121139971.1574.200.camel@serendipity.dogma.lan> References: <1121139971.1574.200.camel@serendipity.dogma.lan> Message-ID: <1121156217.10841.40.camel@mccallum.corsepiu.local> Hi Alexander, partial review of your spec, without having tried to build your package: On Tue, 2005-07-12 at 05:46 +0200, Alexander Dalloz wrote: > gyrus: GNOME Cyrus-IMAPd Administrator > > gyrus is a GNOME based tool for the administration of mailboxes in > Cyrus-IMAPd servers. It allows to control user quotas, create and remove > mailboxes, and to manipulate the Access Control List for each mailbox. > > http://gyrus.gnome.cl/ > > At the moment gyrus isn't yet the tool it promises from summary. It may > though be a help. > > Be touch to criticize this packaging: > > http://www.uni-x.org/gyrus.spec > Name: gyrus > Summary: GNOME Cyrus-IMAPd Administrator > Version: 0.3.3 > Release: 1%{?dist} > License: GPL > Group: Applications/Mail > URL: http://gyrus.gnome.cl/ > Source0: %{name}-%{version}.tar.bz2 This should be an absolute URL pointing the source tarball. > BuildPrereq: GConf2-devel >= 2.0.0 > BuildPrereq: gtk2-devel >= 2.4.0 > BuildPrereq: libglade2-devel >= 2.0.0 > BuildPrereq: libgnomeui-devel >= 2.6.0 > BuildPrereq: gnet2-devel >= 2.0.0 BuildPrereq is an rpm anachronism. Using "BuildRequires:" instead is preferred. > Requires: GConf2 >= 2.0.0 > Requires: libglade2 >= 2.0.0 > Requires: gnet2 >= 2.0.0 In general, most such Requires are superfluous - Please check. > %makeinstall Is this package using automake or libtool? Then, you will want to prefer using make DESTDIR=%buildroot install Ralf From veillard at redhat.com Tue Jul 12 09:53:49 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 12 Jul 2005 05:53:49 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <1121123856.4423.8.camel@ignacio.lan> References: <1121123856.4423.8.camel@ignacio.lan> Message-ID: <20050712095349.GE7527@redhat.com> On Mon, Jul 11, 2005 at 07:17:36PM -0400, Ignacio Vazquez-Abrams wrote: > xmlstarlet: A set of command line utilities for XML > > XMLStarlet is a set of command line utilities (tools) which can be used > to transform, query, validate, and edit XML documents and files using > simple set of shell commands in similar way it is done for plain text > files using UNIX grep, sed, awk, diff, patch, join, etc commands. > > This set of command line utilities can be used by those who deal with > many XML documents on UNIX shell command prompt as well as for automated > XML processing with shell scripts. > > http://fedora.ivazquez.net/files/extras/xmlstarlet.spec > http://fedora.ivazquez.net/files/extras/xmlstarlet-1.0.1-1.src.rpm This would allow me to close the following bug :-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134613 to me xmlstarlet sounds a good candidate for Extras, the package seems to build and work but I'm a bit annoyed by the name of the binary: /usr/bin/xml I would really prefer /usr/bin/xmlstarlet, first because it would be less likely to generate conflicts or troubles, second because the man page actually use the "xmlstarlet" name. If that renaming is done I would be okay to sponsor that package if needed. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 12 09:59:07 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 12 Jul 2005 11:59:07 +0200 Subject: Request for review : gkrellm-aclock & gkrellm-freq Message-ID: <20050712115907.1023042d@python2> Hi, I've finally reinstalled my main laptop with FC4, and was missing these two gkrellm plugins I heavily depend on ;-) so I've split them out of my gkrellm-plugins package to include them into Extras. I may also be doing the same shortly for other plugins. For now : gkrellm-aclock & gkrellm-freq http://ftp.es6.freshrpms.net/tmp/extras/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.05 0.19 0.30 From markmc at redhat.com Tue Jul 12 11:23:19 2005 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 12 Jul 2005 12:23:19 +0100 Subject: Icons and menus In-Reply-To: <1120635097.15736.264.camel@laurel.intra.city-fan.org> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> Message-ID: <1121167399.6273.52.camel@blaa> Hi, On Wed, 2005-07-06 at 08:31 +0100, Paul Howarth wrote: > Yesterday I got a bug report on the bittorrent-gui package, the issue > being that no icon appeared in the user's menu for the application. ... > Bug report: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162465 > Okay, unless I'm mistaken, the reporter is saying that the menu item for the app does appear in the menu, but the icon does not appear in the menu item. If so, the issue is possibly that there's an icon cache in /usr/share/pixmaps (icon-theme.cache) where you're installing the icon and since you're not updating the icon cache (with gtk-update-icon-cache), the panel never sees the new icon. Now, there should be no icon-theme.cache in /usr/share/pixmaps - none of the Extras or Core packages create one AFAICS, so the cache was either created by some bogus package in the past or the user created the cache himself. Either way, I think its a spurious problem which the user can fix by deleting /usr/share/pixmaps/icon-theme.cache. Cheers, Mark. ( As an aside, these days apps should be installing their icon in $(datadir)/icons/hicolor/48x48/apps instead of $(datadir)/pixmaps (as suggested by the icon theme spec) and gtk-update-icon-cache should be run in %post and %postun ala: $post touch --no-create %{_datadir}/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache -q %{_datadir}/icons/hicolor fi ) From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 12 11:30:59 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 12 Jul 2005 13:30:59 +0200 Subject: Icons and menus In-Reply-To: <1121167399.6273.52.camel@blaa> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> <1121167399.6273.52.camel@blaa> Message-ID: <20050712133059.10719ec1@python2> Mark McLoughlin wrote : > > Bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162465 > > > Okay, unless I'm mistaken, the reporter is saying that the menu item > for the app does appear in the menu, but the icon does not appear in the > menu item. > > If so, the issue is possibly that there's an icon cache > in /usr/share/pixmaps (icon-theme.cache) where you're installing the > icon and since you're not updating the icon cache (with > gtk-update-icon-cache), the panel never sees the new icon. > > Now, there should be no icon-theme.cache in /usr/share/pixmaps - none > of the Extras or Core packages create one AFAICS, so the cache was > either created by some bogus package in the past or the user created the > cache himself. > > Either way, I think its a spurious problem which the user can fix by > deleting /usr/share/pixmaps/icon-theme.cache. Thanks for the clarifications! I'll check to see if I don't provide any "broken" packages that would be creating an icon cache in /usr/share/pixmaps, as I've already seen the problem too. > ( > As an aside, these days apps should be installing their icon > in $(datadir)/icons/hicolor/48x48/apps instead of $(datadir)/pixmaps > (as suggested by the icon theme spec) and gtk-update-icon-cache > should be run in %post and %postun ala: > > $post > touch --no-create %{_datadir}/icons/hicolor > if [ -x /usr/bin/gtk-update-icon-cache ]; then > gtk-update-icon-cache -q %{_datadir}/icons/hicolor > fi > ) Seems a bit overkill. This should work the same, right? %post gtk-update-icon-cache -q -f %{_datadir}/icons/hicolor || : Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 2.39 1.35 0.82 From paul at city-fan.org Tue Jul 12 12:53:17 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 12 Jul 2005 13:53:17 +0100 Subject: CFLAGS in python noarch packages Message-ID: <42D3BD3D.1070504@city-fan.org> The fedora-rpmdevtools package contains a template for a python package with %build as: CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build This compares with the perl equivalent of: CFLAGS="$RPM_OPT_FLAGS" %{__perl} Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" For perl noarch packages, it's usual to strip out the optimization flags, resulting in: %{__perl} Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} Does the same apply in python, i.e. reduce to: %{__python} setup.py build Looking at a few python packages in cvs, everyone seems to be retaining the CFLAGS setting; is this necessary or even useful? Paul. From rc040203 at freenet.de Tue Jul 12 13:24:34 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 Jul 2005 15:24:34 +0200 Subject: CFLAGS in python noarch packages In-Reply-To: <42D3BD3D.1070504@city-fan.org> References: <42D3BD3D.1070504@city-fan.org> Message-ID: <1121174674.10841.65.camel@mccallum.corsepiu.local> On Tue, 2005-07-12 at 13:53 +0100, Paul Howarth wrote: > The fedora-rpmdevtools package contains a template for a python package > with %build as: I know too little about python to be able to comment on it, but having investigated a bit recently on the perl stuff, ... > CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build > > This compares with the perl equivalent of: > > CFLAGS="$RPM_OPT_FLAGS" %{__perl} Makefile.PL INSTALLDIRS=vendor > make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" This construct is arguable. IMO, it can be reduced to %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" make %{?_smp_mflags} > For perl noarch packages, it's usual to strip out the optimization > flags, resulting in: > > %{__perl} Makefile.PL INSTALLDIRS=vendor > make %{?_smp_mflags} This is only partially true. You can remove OPTIMIZE and CFLAGS for noarch-rpms, because CFLAGS etc. are meaningless for noarch-rpms. If you omit them for binary packages, in most cases (at least in ExtUtils::MakeMaker based configurations), a default set of OPTIMIZE flags will be used, which is identical to RPM_OPT_FLAGS. I.e. the rpm spec will be using the CFLAGS of the rpm base-architecture, but will not acknowledge the target architecture (rpmbuild --target=...). To make perl-rpms target-architecture aware, depending on a package's internals, RPM_OPT_FLAGS must be passed to a package's configuration. In most cases this is OPTIMIZE. > Does the same apply in python, i.e. reduce to: > > %{__python} setup.py build > > Looking at a few python packages in cvs, everyone seems to be retaining > the CFLAGS setting; is this necessary or even useful? Probably. c.f. above. Ralf From rc040203 at freenet.de Tue Jul 12 13:31:14 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 Jul 2005 15:31:14 +0200 Subject: CFLAGS in python noarch packages In-Reply-To: <1121174674.10841.65.camel@mccallum.corsepiu.local> References: <42D3BD3D.1070504@city-fan.org> <1121174674.10841.65.camel@mccallum.corsepiu.local> Message-ID: <1121175074.10841.69.camel@mccallum.corsepiu.local> On Tue, 2005-07-12 at 15:24 +0200, Ralf Corsepius wrote: > On Tue, 2005-07-12 at 13:53 +0100, Paul Howarth wrote: > > Does the same apply in python, i.e. reduce to: > > > > %{__python} setup.py build > > > > Looking at a few python packages in cvs, everyone seems to be retaining > > the CFLAGS setting; is this necessary or even useful? > > Probably. c.f. above. Sorry, I should have looked into the subject ... ;) Boilerplate answer: CFLAGS must not be used in any noarch package, nor may it be meaningful to noarch packages. If a "noarch package" somewhere uses CFLAGS, it is not a noarch package. Ralf From tcallawa at redhat.com Tue Jul 12 14:04:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 12 Jul 2005 09:04:56 -0500 Subject: APPROVED: perl-Template-Toolkit In-Reply-To: <42D372CD.1080001@linux-kernel.at> References: <1121107067.2892.308.camel@localhost.localdomain> <42D372CD.1080001@linux-kernel.at> Message-ID: <1121177096.30899.0.camel@localhost.localdomain> On Tue, 2005-07-12 at 09:35 +0200, Oliver Falk wrote: > On 07/11/2005 08:37 PM, Ville Skytt? wrote: > > The Template Toolkit is a collection of modules which implement a > > fast, flexible, powerful and extensible template processing system. > > > > Reviewer: Ville Skytt? > > Maintainer: Tom Callaway > > Will it be available for FC[1,2,3,4]? 3 and 4, yes. :) The other two are in maintenance only mode. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From markmc at redhat.com Tue Jul 12 14:18:48 2005 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 12 Jul 2005 15:18:48 +0100 Subject: Icons and menus In-Reply-To: <20050712133059.10719ec1@python2> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> <1121167399.6273.52.camel@blaa> <20050712133059.10719ec1@python2> Message-ID: <1121177928.6273.89.camel@blaa> Hi, FWIW, it sounds like it'll be fixed in gtk+ by ignoring icon caches which aren't accompanied by and index.theme file (like /usr/share/pixmaps) and by making gtk-update-icon-cache not generate an icon cache where an index.theme file doesn't exist. See: http://bugzilla.gnome.org/show_bug.cgi?id=310131 On Tue, 2005-07-12 at 13:30 +0200, Matthias Saou wrote: > Mark McLoughlin wrote : > > > > Bug report: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162465 > > > > > Okay, unless I'm mistaken, the reporter is saying that the menu item > > for the app does appear in the menu, but the icon does not appear in the > > menu item. > > > > If so, the issue is possibly that there's an icon cache > > in /usr/share/pixmaps (icon-theme.cache) where you're installing the > > icon and since you're not updating the icon cache (with > > gtk-update-icon-cache), the panel never sees the new icon. > > > > Now, there should be no icon-theme.cache in /usr/share/pixmaps - none > > of the Extras or Core packages create one AFAICS, so the cache was > > either created by some bogus package in the past or the user created the > > cache himself. > > > > Either way, I think its a spurious problem which the user can fix by > > deleting /usr/share/pixmaps/icon-theme.cache. > > Thanks for the clarifications! I'll check to see if I don't provide any > "broken" packages that would be creating an icon cache > in /usr/share/pixmaps, as I've already seen the problem too. I did a grep in Fedora Core and Fedora Extras devel branches and didn't find any packages which create an icon cache in /usr/share/pixmaps. > > ( > > As an aside, these days apps should be installing their icon > > in $(datadir)/icons/hicolor/48x48/apps instead of $(datadir)/pixmaps > > (as suggested by the icon theme spec) and gtk-update-icon-cache > > should be run in %post and %postun ala: > > > > $post > > touch --no-create %{_datadir}/icons/hicolor > > if [ -x /usr/bin/gtk-update-icon-cache ]; then > > gtk-update-icon-cache -q %{_datadir}/icons/hicolor > > fi > > ) > > Seems a bit overkill. This should work the same, right? > > %post > gtk-update-icon-cache -q -f %{_datadir}/icons/hicolor || : Looks reasonable, yes. The former is just what all the packages in Fedora Core do. Cheers, Mark. From kaboom at oobleck.net Tue Jul 12 14:31:07 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 12 Jul 2005 10:31:07 -0400 (EDT) Subject: Request for review: keychain In-Reply-To: <1121134236.26750.74.camel@ernie> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> Message-ID: On Mon, 11 Jul 2005, Ed Hill wrote: > And, if possible, it would be nice if we could get a second opinion on > the security implications of the actual "keychain" shell script. I'm > *no* security guru and maybe someone more knowledgeable could step in > and say the script looks OK. Or that its probably OK since its widely > used and widely reviewed...? It's in the same category as sudo: you can do Stupid Stuff with it if you try, or you can use it sanely ;-) later, chris From Jochen at herr-schmitt.de Tue Jul 12 15:19:39 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 12 Jul 2005 17:19:39 +0200 Subject: New Package: git In-Reply-To: <41782.129.42.161.36.1121113821.squirrel@jdub.homelinux.org> References: <20050711162113.GA30227@myhome> <52934.129.42.161.36.1121109018.squirrel@jdub.homelinux.org> <0MKwtQ-1Ds4cL1Og0-00020u@mrelayeu.kundenserver.de> <41782.129.42.161.36.1121113821.squirrel@jdub.homelinux.org> Message-ID: <0ML21M-1DsMY923Xa-0000O2@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 11 Jul 2005 15:30:21 -0500 (CDT), you wrote: >There hasn't been an announce message on the git mailing list, and there >is no tarball. Those RPMs are trial RPMs, as specified in this thread: > >http://marc.theaimsgroup.com/?l=git&m=112104471808807&w=2 > >Plus, those were just built yesterday. From the same thread as above, it >almost seems as if Linus is trying to pave the way for cogito to be >separated. Perhaps we should have some patience and wait for a few more >days to see what develops. Thank you for your explanation. I would wait some days and see what happens. As a last option, we my replace the tar-Ball in the Source RPM by an other downloaded tarball. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQtPfnE9gByurcX4MEQJSrgCgo4W2HTrcmuv+LtmTm0RtYhHU31sAoIqP Ptj1sVssorBxauKo2QFaCanG =Wa/D -----END PGP SIGNATURE----- From pertusus at free.fr Tue Jul 12 15:13:40 2005 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 12 Jul 2005 17:13:40 +0200 Subject: clean mock root without cleaning everything Message-ID: <20050712151340.GA7328@free.fr> Hi, Is there some mock documentation/tips/faq in addition to the README? I would like to clean the packages installed as prerequisites for a previous mock build, but not the base packages as they take much longer to install. It isn't possible to simply do a chroot /var/lib/mock/root as I don't have enough privileges. Is there an helper that allows to rpm -e or yum remove in the mock chroot? -- Pat From ville.skytta at iki.fi Tue Jul 12 15:56:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 12 Jul 2005 18:56:30 +0300 Subject: Request for Review: nethack In-Reply-To: <20050711185610.GA6774@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <1121064620.2892.192.camel@localhost.localdomain> <1121065204.2892.195.camel@localhost.localdomain> <20050711123654.GA6289@tomservo.boston.redhat.com> <1121094015.2892.221.camel@localhost.localdomain> <20050711150709.GB6416@tomservo.boston.redhat.com> <1121096783.2892.258.camel@localhost.localdomain> <20050711185610.GA6774@tomservo.boston.redhat.com> Message-ID: <1121183790.22425.23.camel@localhost.localdomain> On Mon, 2005-07-11 at 14:56 -0400, Luke Macken wrote: > On Mon, Jul 11, 2005 at 06:46:23PM +0300, Ville Skytt? wrote: > | > I just not seeing how we > | > benefit from restricting Fedora users to install *extremely* unstable > | > graphical versions of a text based game. > | > | Where can I read more about this extreme unstability? > > https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00535.html > > The game does not idle very well, and is pretty much unplayable at > 1024x768 if you have any sort of desktop panel Yep, I read that message, but it didn't occur to me as extreme unstability. > (i haven't looked into > changing the res of the game, but it could be possible). It is, in jtp_opts.txt. But see below. > I feel strongly about having an up-to-date version in the tree Agreed. > (mostly > because a bug in 3.4.1 prevented me from ascending in the past). Ouch! > I guess my argument is that I think we should give users the choice of > any nethack frontend that anyone is willing to package for Extras and > not restrict them to having to install something graphical if they > aren't even going to use it. I took a look at Vulture's Eye, and it's a no go at the moment, as it introduces new "issues" to the tty version, and apart from the version upgrade, doesn't help with the other issues people have mentioned in this thread. So, I'm starting to agree with you, plus getting the feeling that we should get the GUI version out of vanilla's way. The vanilla one should probably have "Obsoletes: nethack-falconseye <= 1.9.4-6.a". From ville.skytta at iki.fi Tue Jul 12 16:09:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 12 Jul 2005 19:09:13 +0300 Subject: Request for review: keychain In-Reply-To: <1121139082.1574.182.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> <1121139082.1574.182.camel@serendipity.dogma.lan> Message-ID: <1121184553.22425.35.camel@localhost.localdomain> On Tue, 2005-07-12 at 05:31 +0200, Alexander Dalloz wrote: > Both the .spec and the src.rpm are renewed and available at: > > http://www.uni-x.org/keychain.spec > http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm Bumping the release when you make updates and adding a changelog entry would be useful for tracking purposes. Anyway, I have a local package of this too, here's some cosmetic stuff that mine has but yours doesn't (maybe yet? ;)): - In %prep: sed -i -e 's|/usr/ucb:||' keychain - A docs patch, see attachment. (The reason for the "which" is that home dirs may be shared accross hosts, and it's possible that all of them don't have keychain installed.) The reason why I hadn't submitted this package to Extras yet is its annoying interaction with the ssh-agent launched by FC's gdm. I use gdm and KDE, and have this in my ~/.bash_profile: which keychain &>/dev/null && keychain -q id_dsa [[ -f $HOME/.keychain/$HOSTNAME-sh ]] && \ source $HOME/.keychain/$HOSTNAME-sh When logging in through gdm, while KDE starts up, I get a ssh-askpass dialog prompting for the passphrase, which is ok. Then, I type the passphrase in, it's accepted and life seems good. But when I start up a Konsole session, ssh'ing somewhere results in the passphrase query. It seems that there are actually two ssh-agents launched, and the passphrases I typed at KDE startup ended up in the "wrong" one. Very annoying, and I haven't found a solution yet. Ideas? -------------- next part -------------- A non-text attachment was scrubbed... Name: keychain-docs.patch Type: text/x-patch Size: 2640 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Jul 12 16:18:51 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 12 Jul 2005 19:18:51 +0300 Subject: Request for review: keychain In-Reply-To: <1121141507.26750.89.camel@ernie> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> <1121141507.26750.89.camel@ernie> Message-ID: <1121185131.22425.44.camel@localhost.localdomain> On Tue, 2005-07-12 at 00:11 -0400, Ed Hill wrote: > On Mon, 2005-07-11 at 20:54 -0700, Chip Turner wrote: > > It would be nicer to have some sort of opt-in, perhaps in the form of > > ~/.keychainrc, which, if present, causes it to be source'd and then, > > if set, use an environment variable KEYS to list the keys the user > > wants, otherwise default to id_dsa. This way a user just specifies > > their keys that feed the command line (and perhaps other command line > > options such as timeout). > > +1 -- the above opt-in [...] Yep, keychain startup should definitely should be an opt-_in_, and not enabled by default. I have had problems with it effectively preventing use of WinSCP and/or Konqueror's fish:// protocol in the past (can't remember which, or if both), and the gdm interaction issue I mentioned is another message is another annoying "feature". The latter could be a local config issue, though. From chrisw at osdl.org Tue Jul 12 16:49:01 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 12 Jul 2005 09:49:01 -0700 Subject: New Package: git In-Reply-To: <41782.129.42.161.36.1121113821.squirrel@jdub.homelinux.org> References: <20050711162113.GA30227@myhome> <52934.129.42.161.36.1121109018.squirrel@jdub.homelinux.org> <0MKwtQ-1Ds4cL1Og0-00020u@mrelayeu.kundenserver.de> <41782.129.42.161.36.1121113821.squirrel@jdub.homelinux.org> Message-ID: <20050712164901.GS19052@shell0.pdx.osdl.net> * Josh Boyer (jwboyer at jdub.homelinux.org) wrote: > Plus, those were just built yesterday. From the same thread as above, it > almost seems as if Linus is trying to pave the way for cogito to be > separated. Perhaps we should have some patience and wait for a few more > days to see what develops. Yes, that's exactly what we're trying to accomplish. thanks, -chris From steve at silug.org Tue Jul 12 16:49:48 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 12 Jul 2005 11:49:48 -0500 Subject: Request for review: perl-eperl Message-ID: <20050712164948.GA20985@osiris.silug.org> I just tried to update the Hardware HOWTO and found that my ancient ePerl-based build wouldn't work, so I whipped up a new ePerl package: http://ftp.kspei.com/pub/steve/rpms/perl-eperl-2.2.14-1.src.rpm d783bab15e2f9482f1683e22c858eac2 perl-eperl-2.2.14-1.src.rpm Giving credit where credit is due, I should note that I'm including the current Debian patch whole. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chrisw at osdl.org Tue Jul 12 16:54:09 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 12 Jul 2005 09:54:09 -0700 Subject: Request for review: cogito In-Reply-To: <1121029014.2685.12.camel@yoda.jdub.homelinux.org> References: <20050710205013.91A371809FD@magilla.sf.frob.com> <1121029014.2685.12.camel@yoda.jdub.homelinux.org> Message-ID: <20050712165409.GT19052@shell0.pdx.osdl.net> * Josh Boyer (jwboyer at jdub.homelinux.org) wrote: > On Sun, 2005-07-10 at 13:50 -0700, Roland McGrath wrote: > > > Is there any way to separate cogito and git into two different packages? > > > That way one could install git apart from cogito. > > > > The upstream cogito is a unified package as it stands. > > Crap. If it ever decides to depend on git instead of include it, can I > assume that the package will be changed to depend on a new git package? Yes you can, that's the goal. The problem is git changes are still breaking cogito, and IIRC, cogito has local git changes that haven't made it back upstream to git yet. But, it is getting closer. thanks, -chris From chrisw at osdl.org Tue Jul 12 16:56:52 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 12 Jul 2005 09:56:52 -0700 Subject: Request for review: cogito In-Reply-To: <1121039694.2685.25.camel@yoda.jdub.homelinux.org> References: <20050710191609.1995B1809FD@magilla.sf.frob.com> <1121039694.2685.25.camel@yoda.jdub.homelinux.org> Message-ID: <20050712165652.GU19052@shell0.pdx.osdl.net> * Josh Boyer (jwboyer at jdub.homelinux.org) wrote: > On Sun, 2005-07-10 at 12:16 -0700, Roland McGrath wrote: > > In http://people.redhat.com/~roland/fedora/4/ please find cogito.spec, > > as well as a src.rpm and repodata you can use to install the binaries there. > > > > This is one of the GIT-based SCM tools, and apparently one of the most > > straightforward ways to track Linus's kernel development. > > > > I started with an upstream rpm and cleaned up the spec file. It's pretty > > trivial. I haven't actually put any packages into extras before, so I > > might have overlooked some conventions. Please advise. > > Ok, regardless of the unified or broken out git issue, I think this > package is ready to be included. Here are a few questions on the spec > file: > > - Is there a reason the Requires: list files instead of their respective > packages? > > - coreutils is probably not needed as a requires since everything > requires it. No harm in it being there though > > - Is the Obsoletes: git needed? In my limited knowledge, I'm just > wondering if this will cause upgrade problems when/if cogito and git are > split into separate packages in the future. I actually just removed it a day or two ago. It was there from the original cogito packages which were just called git (when cogito was simply called git-pasky, and it wasn't clear that git would ever be a standalone package separate from cogito). thanks, -chris From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 12 17:25:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 12 Jul 2005 19:25:25 +0200 Subject: Icons and menus In-Reply-To: <1121177928.6273.89.camel@blaa> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> <1121167399.6273.52.camel@blaa> <20050712133059.10719ec1@python2> <1121177928.6273.89.camel@blaa> Message-ID: <20050712192525.7a55a0a3@python2> Mark McLoughlin wrote : > Hi, > FWIW, it sounds like it'll be fixed in gtk+ by ignoring icon caches > which aren't accompanied by and index.theme file > (like /usr/share/pixmaps) and by making gtk-update-icon-cache not > generate an icon cache where an index.theme file doesn't exist. See: > > http://bugzilla.gnome.org/show_bug.cgi?id=310131 Probably a good thing. Still : The bug reported initially mentioned doesn't seem to necessarily be caused by an icon cache being present. A minute ago, I ran "yum install flumotion", and the new entry in my GNOME menu doesn't show any icon. The desktop file seems fine and the /usr/share/pixmaps/flumotion.png file is present. $ ls /usr/share/pixmaps/*cache* ls: /usr/share/pixmaps/*cache*: No such file or directory I've looked through the directory and don't see anything unusual. Last times this happened to me (on other computers), the icon was there after logging out and back in, or after the next bootup, pretty much like the report you got it seems. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 1.05 0.81 0.61 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 12 17:37:31 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 12 Jul 2005 19:37:31 +0200 Subject: Request for review : gkrellm-aclock & gkrellm-freq In-Reply-To: <20050712115907.1023042d@python2> References: <20050712115907.1023042d@python2> Message-ID: <20050712193731.0a752eaa@python2> Matthias Saou wrote : > For now : gkrellm-aclock & gkrellm-freq > > http://ftp.es6.freshrpms.net/tmp/extras/ And as soon as I get those two reviewed, I'll send out gkrellm-xmms and gkrellm-bmp next :-D Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 1.73 1.17 0.74 From ville.skytta at iki.fi Tue Jul 12 19:41:06 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 12 Jul 2005 22:41:06 +0300 Subject: Request for review: gdome2 Message-ID: <1121197266.3420.3.camel@localhost.localdomain> libxml2 2.6.20 fixes XPath issues that affected gdome2, so now that an errata is out, here's a request for review for it. For me, this is the root of a smallish chain of missing dependencies towards getting XSH (http://xsh.sf.net/) to Extras: gdome2 is a fast, light and complete DOM level 2 implementation based on libxml2. Although it has been written for the GNOME project, it can be used stand-alone. http://gdome2.cs.unibo.it/ http://cachalot.mine.nu/4/SRPMS/gdome2-0.8.1-0.2.src.rpm From bugs.michael at gmx.net Tue Jul 12 20:09:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Jul 2005 22:09:39 +0200 Subject: Request for review : gkrellm-aclock & gkrellm-freq In-Reply-To: <20050712193731.0a752eaa@python2> References: <20050712115907.1023042d@python2> <20050712193731.0a752eaa@python2> Message-ID: <20050712220939.56fa3640.bugs.michael@gmx.net> On Tue, 12 Jul 2005 19:37:31 +0200, Matthias Saou wrote: > Matthias Saou wrote : > > > For now : gkrellm-aclock & gkrellm-freq > > > > http://ftp.es6.freshrpms.net/tmp/extras/ Packaging looks good, except you need to add an explicit dependency on gkrellm to both. gkrellm-freq didn't build with -fPIC here. And a new release of gkrellm-alock was made in January. Consider them approved and hence feel free to fix in CVS. From ivazquez at ivazquez.net Tue Jul 12 22:39:21 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 12 Jul 2005 18:39:21 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <20050712095349.GE7527@redhat.com> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> Message-ID: <1121207961.4423.33.camel@ignacio.lan> On Tue, 2005-07-12 at 05:53 -0400, Daniel Veillard wrote: > On Mon, Jul 11, 2005 at 07:17:36PM -0400, Ignacio Vazquez-Abrams wrote: > > http://fedora.ivazquez.net/files/extras/xmlstarlet.spec > > http://fedora.ivazquez.net/files/extras/xmlstarlet-1.0.1-1.src.rpm > > to me xmlstarlet sounds a good candidate for Extras, the package seems > to build and work but I'm a bit annoyed by the name of the binary: > /usr/bin/xml > I would really prefer /usr/bin/xmlstarlet, first because it would be > less likely to generate conflicts or troubles, second because the > man page actually use the "xmlstarlet" name. > If that renaming is done I would be okay to sponsor that package if needed. Updated, with a note in %description. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ed at eh3.com Tue Jul 12 23:53:50 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 12 Jul 2005 19:53:50 -0400 Subject: Request for review: keychain In-Reply-To: <1121184553.22425.35.camel@localhost.localdomain> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> <1121139082.1574.182.camel@serendipity.dogma.lan> <1121184553.22425.35.camel@localhost.localdomain> Message-ID: <1121212431.15220.10.camel@ernie> On Tue, 2005-07-12 at 19:09 +0300, Ville Skytt? wrote: > On Tue, 2005-07-12 at 05:31 +0200, Alexander Dalloz wrote: > > > Both the .spec and the src.rpm are renewed and available at: > > > > http://www.uni-x.org/keychain.spec > > http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm > > Bumping the release when you make updates and adding a changelog entry > would be useful for tracking purposes. Hi Alexander & Ville, Yeah, that confused me too but I looked and the three 'please fix' items were indeed changed. Others seem to think its OK from a security standpoint which is good. I'll send an APPROVED message in a few minutes. And maybe some of the other suggested changes can be added after the CVS import? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From andreas at bawue.net Wed Jul 13 00:00:59 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 13 Jul 2005 02:00:59 +0200 (CEST) Subject: Request for review: perl-Crypt-Blowfish / CBC Message-ID: Hello, I packaged two crypt related perl packages. perl-Crypt-CBC: This is Crypt::CBC, a Perl-only implementation of the cryptographic cipher block chaining mode (CBC). In combination with a block cipher such as Crypt::DES or Crypt::IDEA, you can encrypt and decrypt messages of arbitrarily long length. The encrypted messages are compatible with the encryption format used by SSLeay. SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-CBC/ perl-Crypt-Blowfish: This is Crypt::Blowfish version 2.09, an XS-based implementation of the Blowfish cryptography algorithm designed by Bruce Schneier. It's designed to take full advantage of Crypt::CBC when desired. Blowfish keys may be up to 448 bits (56 bytes) long. SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-Blowfish/ If anyone could take please take a look at the specs and approve them. thx, andreas From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 13 07:49:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jul 2005 09:49:52 +0200 Subject: Request for review : gkrellm-aclock & gkrellm-freq In-Reply-To: <20050712220939.56fa3640.bugs.michael@gmx.net> References: <20050712115907.1023042d@python2> <20050712193731.0a752eaa@python2> <20050712220939.56fa3640.bugs.michael@gmx.net> Message-ID: <20050713094952.4b16901f@python2> Michael Schwendt wrote : > On Tue, 12 Jul 2005 19:37:31 +0200, Matthias Saou wrote: > > > Matthias Saou wrote : > > > > > For now : gkrellm-aclock & gkrellm-freq > > > > > > http://ftp.es6.freshrpms.net/tmp/extras/ > > Packaging looks good, except you need to add an explicit dependency on > gkrellm to both. gkrellm-freq didn't build with -fPIC here. And a > new release of gkrellm-alock was made in January. Consider them > approved and hence feel free to fix in CVS. Thanks for the review, and especially for catching the missing requirement! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.21 0.57 0.44 From alex at dalloz.de Wed Jul 13 11:37:43 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 13:37:43 +0200 Subject: Request for review: keychain In-Reply-To: <1121212431.15220.10.camel@ernie> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> <1121139082.1574.182.camel@serendipity.dogma.lan> <1121184553.22425.35.camel@localhost.localdomain> <1121212431.15220.10.camel@ernie> Message-ID: <1121254663.1574.209.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Ed Hill um 1:53: > On Tue, 2005-07-12 at 19:09 +0300, Ville Skytt? wrote: > > On Tue, 2005-07-12 at 05:31 +0200, Alexander Dalloz wrote: > > > Both the .spec and the src.rpm are renewed and available at: > > > > > > http://www.uni-x.org/keychain.spec > > > http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm > > > > Bumping the release when you make updates and adding a changelog entry > > would be useful for tracking purposes. Sorry for that, wasn't sure that in review phase all corrections (because of mistakes caused by not already dreaming in rpm building guidelines ;) should be changelogged. I will do now. > Hi Alexander & Ville, > > Yeah, that confused me too but I looked and the three 'please fix' items > were indeed changed. Others seem to think its OK from a security > standpoint which is good. I'll send an APPROVED message in a few > minutes. > > And maybe some of the other suggested changes can be added after the CVS > import? I took your (Ed), Chip's and Ville's suggestion for an opt-in mechanism and am actually writing a small profile script. Think it is better to include it with the rpm from start up. Please give me a short time and I'll then present it here for comments. > Ed Thanks for all constructive help! Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From alex at dalloz.de Wed Jul 13 11:46:49 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 13:46:49 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D37893.9030902@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> Message-ID: <1121255209.1574.219.camel@serendipity.dogma.lan> Am Di, den 12.07.2005 schrieb Oliver Falk um 10:00: > > http://www.uni-x.org/pam_abl-0.2.2-20050110.src.rpm > > http://www.uni-x.org/pam_abl.spec > Tried this, but get the following, if I enable pam_abl in system-auth: > > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > pam_sm_open_session > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > pam_sm_close_session > > :-/ Hi Oliver, on which system does it fail? I am running pam_abl on CentOS4 and it builds and runs properly. That leads me directly to the question: is it necessary to test software builds on FC4 with it's latest gcc? > Specfile: > * Release should be 1%{?dist} Ok, so the dist tag seems to be mandatory, other than the wiki says. > * You should not make > * rpmlint complains: > W: pam_abl non-standard-group Base Group: System Environment/Base would be correct? > E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so Where is that error triggered from? > * Do not add an 'install howto' in the description. Ok, will include a small README.Fedora file. > So far... For sure there are other things as well, but I had no closer > look at the pkg, since it doesn't work here... :-/ > > Best, > Oliver Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From veillard at redhat.com Wed Jul 13 11:52:29 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 13 Jul 2005 07:52:29 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <1121207961.4423.33.camel@ignacio.lan> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> Message-ID: <20050713115228.GI8191@redhat.com> On Tue, Jul 12, 2005 at 06:39:21PM -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-07-12 at 05:53 -0400, Daniel Veillard wrote: > > If that renaming is done I would be okay to sponsor that package if needed. > > Updated, with a note in %description. I started to look up more closely to teh spec file, there is a number of annoying things, sorry I didn't looked more closely in the first pass: BuildRequires: misses libxml2-devel I think Requires should at least list libxml2 Why link against the static versions of the libraries ? make EXTRA_LIBS="/usr/lib/libgcrypt.a /usr/lib/libgpg-error.a" Can't this check be done the normal way from configure ? paphio:~ -> ldd /usr/bin/xmlstarlet libz.so.1 => /usr/lib/libz.so.1 (0x00ae8000) libm.so.6 => /lib/tls/libm.so.6 (0x00ef6000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00ce4000) libdl.so.2 => /lib/libdl.so.2 (0x00deb000) libc.so.6 => /lib/tls/libc.so.6 (0x00111000) /lib/ld-linux.so.2 (0x00c3a000) There is a big problem here: libxml2 is not referenced dynamically, it should. I didn't looked at the MAkefile.am or configure but there is something wrong: it should use xml2-config --cflags and xml2-config --libs to interface with libxml2. As a result it also link in -lpthread while this is actaully not needed anymore. I think this is a bit too much to allow this in the current state to get in. It would be cool if you can get those fixed, thanks, Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From dennis.coonich at comcast.net Wed Jul 13 12:03:54 2005 From: dennis.coonich at comcast.net (Dennis Coonich) Date: Wed, 13 Jul 2005 07:03:54 -0500 Subject: CFLAGS in python noarch packages In-Reply-To: <1121175074.10841.69.camel@mccallum.corsepiu.local> References: <42D3BD3D.1070504@city-fan.org> <1121174674.10841.65.camel@mccallum.corsepiu.local> <1121175074.10841.69.camel@mccallum.corsepiu.local> Message-ID: <1121256234.1311.2.camel@localhost.localdomain> On Tue, 2005-07-12 at 15:31 +0200, Ralf Corsepius wrote: > On Tue, 2005-07-12 at 15:24 +0200, Ralf Corsepius wrote: > > On Tue, 2005-07-12 at 13:53 +0100, Paul Howarth wrote: > > > > Does the same apply in python, i.e. reduce to: > > > > > > %{__python} setup.py build > > > > > > Looking at a few python packages in cvs, everyone seems to be retaining > > > the CFLAGS setting; is this necessary or even useful? > > > > Probably. c.f. above. > > Sorry, I should have looked into the subject ... ;) > > Boilerplate answer: CFLAGS must not be used in any noarch package, nor > may it be meaningful to noarch packages. > > If a "noarch package" somewhere uses CFLAGS, it is not a noarch package. > > Ralf > > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From tmraz at redhat.com Wed Jul 13 12:23:47 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 13 Jul 2005 14:23:47 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D37893.9030902@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> Message-ID: <1121257427.5812.71.camel@perun.redhat.usu> On Tue, 2005-07-12 at 10:00 +0200, Oliver Falk wrote: > Tried this, but get the following, if I enable pam_abl in system-auth: > > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > pam_sm_open_session > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > pam_sm_close_session You've added pam_abl to the session stage but it doesn't have this stage implemented (no functionality would be there). It should be added only to the auth and account stages. -- Tomas Mraz From bugs.michael at gmx.net Wed Jul 13 12:31:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Jul 2005 14:31:28 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121255209.1574.219.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> Message-ID: <20050713143128.789b77f6.bugs.michael@gmx.net> On Wed, 13 Jul 2005 13:46:49 +0200, Alexander Dalloz wrote: > Am Di, den 12.07.2005 schrieb Oliver Falk um 10:00: > > > > http://www.uni-x.org/pam_abl-0.2.2-20050110.src.rpm > > > http://www.uni-x.org/pam_abl.spec > > > Tried this, but get the following, if I enable pam_abl in system-auth: > > > > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > > pam_sm_open_session > > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > > pam_sm_close_session > > > > :-/ > > Hi Oliver, > > on which system does it fail? I am running pam_abl on CentOS4 and it > builds and runs properly. > > That leads me directly to the question: is it necessary to test software > builds on FC4 with it's latest gcc? "Yes, of course!" to the latter question. > > Specfile: > > * Release should be 1%{?dist} > > Ok, so the dist tag seems to be mandatory, other than the wiki says. No, it isn't. > > * You should not make > > * rpmlint complains: > > W: pam_abl non-standard-group Base > > Group: System Environment/Base > would be correct? Yes. > > E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so > > Where is that error triggered from? rpmlint examining your PAM file. On x86_64, PAM modules are stored in /lib64/security/..., so it is a mistake to hardcode the path. Just put "pam_abl.so" there. From oliver at linux-kernel.at Wed Jul 13 12:35:46 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 14:35:46 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121257427.5812.71.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> Message-ID: <42D50AA2.10004@linux-kernel.at> On 07/13/2005 02:23 PM, Tomas Mraz wrote: > On Tue, 2005-07-12 at 10:00 +0200, Oliver Falk wrote: > >>Tried this, but get the following, if I enable pam_abl in system-auth: >> >>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>pam_sm_open_session >>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>pam_sm_close_session > > You've added pam_abl to the session stage but it doesn't have this stage > implemented (no functionality would be there). > > It should be added only to the auth and account stages. I just did what the documentation told me to do: /usr/share/pam_abl-0.2.2/conf/system-auth: #%PAM-1.0 auth required /lib/security/$ISA/pam_env.so auth required /lib/security/$ISA/pam_abl.so config=/etc/security/pam_abl.conf auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_abl.so session required /lib/security/$ISA/pam_unix.so So, you tell me, that the documentation is wrong? If so Alexander must change this... In the RPM at least and maybe contact the author of pam_abl to change this... Best, Oliver From oliver at linux-kernel.at Wed Jul 13 12:42:24 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 14:42:24 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121255209.1574.219.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> Message-ID: <42D50C30.9090602@linux-kernel.at> Hi Alexander! On 07/13/2005 01:46 PM, Alexander Dalloz wrote: > Am Di, den 12.07.2005 schrieb Oliver Falk um 10:00: > >>>http://www.uni-x.org/pam_abl-0.2.2-20050110.src.rpm >>>http://www.uni-x.org/pam_abl.spec > > >>Tried this, but get the following, if I enable pam_abl in system-auth: >> >>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>pam_sm_open_session >>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>pam_sm_close_session >> >>:-/ > > on which system does it fail? I am running pam_abl on CentOS4 and it > builds and runs properly. On FC Devel. I have no box here with a clean FC4 :-/ > That leads me directly to the question: is it necessary to test software > builds on FC4 with it's latest gcc? If you want to include the package, it should at least build on development branch fine, to be included in future releases as well. You can, buildrequire gcc33 for example, but I believe it's not a favourite 'workaround', normally all packages should contain patches/fixes to compile with the standard compiler; In case of fc/fe devel branch: gcc-4.0.1. >>Specfile: >>* Release should be 1%{?dist} > > Ok, so the dist tag seems to be mandatory, other than the wiki says. The dist tag must be included at the time the package is imported and to not forget it at this later stage, I always ask to add it at first review, since it doesn't harm anything if you eg. build it on your local machine. >>* You should not make >>* rpmlint complains: >>W: pam_abl non-standard-group Base > > > Group: System Environment/Base > would be correct? Yes, this sounds like a much better choice. :-) >>E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so > > Where is that error triggered from? I guess it comes from the %description section. >>* Do not add an 'install howto' in the description. > > Ok, will include a small README.Fedora file. Yes, %doc README.Fedora sounds like a very good idea. >>So far... For sure there are other things as well, but I had no closer >>look at the pkg, since it doesn't work here... :-/ Best, Oliver From oliver at linux-kernel.at Wed Jul 13 12:49:07 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 14:49:07 +0200 Subject: Buildsys Message-ID: <42D50DC3.8060609@linux-kernel.at> Hi! The buildsys is still down, is it? Best, Oliver From tmraz at redhat.com Wed Jul 13 12:48:54 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 13 Jul 2005 14:48:54 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D50AA2.10004@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> <42D50AA2.10004@linux-kernel.at> Message-ID: <1121258935.5812.73.camel@perun.redhat.usu> On Wed, 2005-07-13 at 14:35 +0200, Oliver Falk wrote: > On 07/13/2005 02:23 PM, Tomas Mraz wrote: > > On Tue, 2005-07-12 at 10:00 +0200, Oliver Falk wrote: > > > >>Tried this, but get the following, if I enable pam_abl in system-auth: > >> > >>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > >>pam_sm_open_session > >>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > >>pam_sm_close_session > > > > You've added pam_abl to the session stage but it doesn't have this stage > > implemented (no functionality would be there). > > > > It should be added only to the auth and account stages. > > I just did what the documentation told me to do: > /usr/share/pam_abl-0.2.2/conf/system-auth: > > #%PAM-1.0 > auth required /lib/security/$ISA/pam_env.so > auth required /lib/security/$ISA/pam_abl.so > config=/etc/security/pam_abl.conf > auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok > auth required /lib/security/$ISA/pam_deny.so > > account required /lib/security/$ISA/pam_unix.so > > password required /lib/security/$ISA/pam_cracklib.so retry=3 type= > password sufficient /lib/security/$ISA/pam_unix.so nullok > use_authtok md5 shadow > password required /lib/security/$ISA/pam_deny.so > > session required /lib/security/$ISA/pam_limits.so > session required /lib/security/$ISA/pam_abl.so > session required /lib/security/$ISA/pam_unix.so > > So, you tell me, that the documentation is wrong? If so Alexander must > change this... In the RPM at least and maybe contact the author of > pam_abl to change this... Yes, I think the documentation is outdated, he should contact the author with the bug report possibly. -- Tomas Mraz From oliver at linux-kernel.at Wed Jul 13 12:49:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 14:49:57 +0200 Subject: Request for review: bwm-ng In-Reply-To: <42D280D6.6040201@linux-kernel.at> References: <42CE7809.3090202@linux-kernel.at> <42D280D6.6040201@linux-kernel.at> Message-ID: <42D50DF5.7020709@linux-kernel.at> On 07/11/2005 04:23 PM, Oliver Falk wrote: > On 07/08/2005 02:56 PM, Oliver Falk wrote: > >> bwm-ng is still in my pipe and here we go: >> >> Summary: A bandwidth monitor >> >> Description >> A small and simple curses base bandwidth monitor. No big features. >> >> SPEC & SRPM: >> http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/bwm-ng >> >> >> (bwm-ng uses the libstatgrab package, which was included today!). >> >> Please review/approve. > > > Noone saw this, did you? Still now answer? :-/ Best, Oliver From tmraz at redhat.com Wed Jul 13 12:52:10 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 13 Jul 2005 14:52:10 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121257427.5812.71.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> Message-ID: <1121259130.5812.76.camel@perun.redhat.usu> On Wed, 2005-07-13 at 14:23 +0200, Tomas Mraz wrote: > On Tue, 2005-07-12 at 10:00 +0200, Oliver Falk wrote: > > Tried this, but get the following, if I enable pam_abl in system-auth: > > > > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > > pam_sm_open_session > > Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: > > pam_sm_close_session > You've added pam_abl to the session stage but it doesn't have this stage > implemented (no functionality would be there). > > It should be added only to the auth and account stages. After looking at the actual sources - it shouldn't be in the account stage either. However this means it won't work correctly for some PAM clients which doesn't call pam_setcred. -- Tomas Mraz From oliver at linux-kernel.at Wed Jul 13 13:01:03 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 15:01:03 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121258935.5812.73.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> <42D50AA2.10004@linux-kernel.at> <1121258935.5812.73.camel@perun.redhat.usu> Message-ID: <42D5108F.502@linux-kernel.at> On 07/13/2005 02:48 PM, Tomas Mraz wrote: > On Wed, 2005-07-13 at 14:35 +0200, Oliver Falk wrote: > >>On 07/13/2005 02:23 PM, Tomas Mraz wrote: >> >>>On Tue, 2005-07-12 at 10:00 +0200, Oliver Falk wrote: >>> >>> >>>>Tried this, but get the following, if I enable pam_abl in system-auth: >>>> >>>>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>>>pam_sm_open_session >>>>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>>>pam_sm_close_session >>> >>>You've added pam_abl to the session stage but it doesn't have this stage >>>implemented (no functionality would be there). >>> >>>It should be added only to the auth and account stages. >> >>I just did what the documentation told me to do: >>/usr/share/pam_abl-0.2.2/conf/system-auth: >> >>#%PAM-1.0 >>auth required /lib/security/$ISA/pam_env.so >>auth required /lib/security/$ISA/pam_abl.so >>config=/etc/security/pam_abl.conf >>auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok >>auth required /lib/security/$ISA/pam_deny.so >> >>account required /lib/security/$ISA/pam_unix.so >> >>password required /lib/security/$ISA/pam_cracklib.so retry=3 type= >>password sufficient /lib/security/$ISA/pam_unix.so nullok >>use_authtok md5 shadow >>password required /lib/security/$ISA/pam_deny.so >> >>session required /lib/security/$ISA/pam_limits.so >>session required /lib/security/$ISA/pam_abl.so >>session required /lib/security/$ISA/pam_unix.so >> >>So, you tell me, that the documentation is wrong? If so Alexander must >>change this... In the RPM at least and maybe contact the author of >>pam_abl to change this... > > Yes, I think the documentation is outdated, he should contact the author > with the bug report possibly. Hmmm.... With only auth required pam_abl.so config=/etc/security/pam_abl.conf in system-auth it works fine, I just blocked root and localhost. :-) Tomas, what do you think, should a package uninstall check for entries in /etc/pam.d/* and remove it? Because if you have configured it and at some time want to remove it, it could happen: Jul 13 14:59:05 moon sshd[20970]: PAM unable to dlopen(/lib/security/pam_abl.so) Jul 13 14:59:05 moon sshd[20970]: PAM [dlerror: /lib/security/pam_abl.so: cannot open shared object file: No such file or directory] Jul 13 14:59:05 moon sshd[20970]: PAM adding faulty module: /lib/security/pam_abl.so :-/ And maybe it should also %ghost /var/lib/abl/hosts.db and users.db, so it get's removed properly at uninstall... Best, Oliver From oliver at linux-kernel.at Wed Jul 13 13:03:41 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 15:03:41 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121259130.5812.76.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> <1121259130.5812.76.camel@perun.redhat.usu> Message-ID: <42D5112D.2070705@linux-kernel.at> On 07/13/2005 02:52 PM, Tomas Mraz wrote: > On Wed, 2005-07-13 at 14:23 +0200, Tomas Mraz wrote: > >>On Tue, 2005-07-12 at 10:00 +0200, Oliver Falk wrote: >> >>>Tried this, but get the following, if I enable pam_abl in system-auth: >>> >>>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>>pam_sm_open_session >>>Jul 12 09:53:24 moon sshd[1944]: PAM unable to resolve symbol: >>>pam_sm_close_session >> >>You've added pam_abl to the session stage but it doesn't have this stage >>implemented (no functionality would be there). >> >>It should be added only to the auth and account stages. > > After looking at the actual sources - it shouldn't be in the account > stage either. However this means it won't work correctly for some PAM > clients which doesn't call pam_setcred. As I wrote, auth is actually fine! Best, Oliver From oliver at linux-kernel.at Wed Jul 13 13:08:44 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 15:08:44 +0200 Subject: [Fwd: Request for review: libdnet] In-Reply-To: <42CE7705.2090002@linux-kernel.at> References: <42CE7705.2090002@linux-kernel.at> Message-ID: <42D5125C.6040302@linux-kernel.at> On 07/08/2005 02:52 PM, Oliver Falk wrote: > This mail should have it's way made here, not to extras-commits. :-/ > However, here we go now... > > -------- Original Message -------- > Subject: Request for review: libdnet > Date: Fri, 08 Jul 2005 14:51:24 +0200 > From: Oliver Falk > To: Fedora Extras CVS commits > > Summary: Simple portable interface to lowlevel networking routines > > Description: > libdnet provides a simplified, portable interface to several > low-level networking routines, including network address > manipulation, kernel arp(4) cache and route(4) table lookup and > manipulation, network firewalling (IP filter, ipfw, ipchains, > pf, ...), network interface lookup and manipulation, raw IP > packet and Ethernet frame, and data transmission. > > > SRPM & SPEC: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet > > > > I'd like to include libdnet as a prerequisite for scanssh. scanssh also > uses libevent, but this is allready in FE. > > Please review/approve. Also here, no answer yet on my mail. :-/ Best, Oliver From oliver at linux-kernel.at Wed Jul 13 13:10:29 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 15:10:29 +0200 Subject: Request for review: perl-Want In-Reply-To: <1120215631.3741.172.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> Message-ID: <42D512C5.4060507@linux-kernel.at> On 07/01/2005 01:00 PM, Ralf Corsepius wrote: > On Fri, 2005-07-01 at 12:36 +0200, Oliver Falk wrote: > >>On 07/01/2005 11:45 AM, Ralf Corsepius wrote: >> >>>On Fri, 2005-07-01 at 11:26 +0200, Oliver Falk wrote: > > >>>This would be a bit more general than what I use, but doesn't have any >>>impact on this package's behavior. >> >>It's just because the perl spec template does it this way, so I >>recommend it as well! > > > Let me put it this way: To me, all that matters is function. > > So, I am not going to adopt a template for stylish reasons, when I have > something that "appears to work" for years. > > If others feel "slavishly hanging on to templates is a good thing", I am > giving them "card blanche" to modify my perl-rpm-specs after cvs check > in. owners.list doesn't show you as owner for perl-Want. Please don't forget to add it. Best, Oliver From rc040203 at freenet.de Wed Jul 13 13:23:16 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jul 2005 15:23:16 +0200 Subject: Request for review: perl-Want In-Reply-To: <42D512C5.4060507@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> <42D512C5.4060507@linux-kernel.at> Message-ID: <1121260996.11257.22.camel@mccallum.corsepiu.local> On Wed, 2005-07-13 at 15:10 +0200, Oliver Falk wrote: > owners.list doesn't show you as owner for perl-Want. Please don't forget > to add it. You are barking up the wrong tree: * The perl-Want (added 05-07-01) module predates owners.list (added 05-07-11). * I don't recall having seen any formal "call for adding yourself to owners.list" nor can I find any trace of owners.list on the wiki. Ralf From oliver at linux-kernel.at Wed Jul 13 13:39:52 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 15:39:52 +0200 Subject: Request for review: perl-Want In-Reply-To: <1121260996.11257.22.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> <42D512C5.4060507@linux-kernel.at> <1121260996.11257.22.camel@mccallum.corsepiu.local> Message-ID: <42D519A8.40908@linux-kernel.at> On 07/13/2005 03:23 PM, Ralf Corsepius wrote: > On Wed, 2005-07-13 at 15:10 +0200, Oliver Falk wrote: > >>owners.list doesn't show you as owner for perl-Want. Please don't forget >>to add it. > > You are barking up the wrong tree: > * The perl-Want (added 05-07-01) module predates owners.list (added > 05-07-11). Yes, that's correct, but perl-Want was never added to the owners.list and also there never was a request on BugzillAdmin, afaik. > * I don't recall having seen any formal "call for adding yourself to > owners.list" nor can I find any trace of owners.list on the wiki. http://fedoraproject.org/wiki/Extras/BugzillaAdmin https://www.redhat.com/archives/fedora-maintainers/2005-July/msg00030.html Best, Oliver From tmraz at redhat.com Wed Jul 13 13:44:20 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 13 Jul 2005 15:44:20 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D5112D.2070705@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> <1121259130.5812.76.camel@perun.redhat.usu> <42D5112D.2070705@linux-kernel.at> Message-ID: <1121262260.5812.80.camel@perun.redhat.usu> On Wed, 2005-07-13 at 15:03 +0200, Oliver Falk wrote: > On 07/13/2005 02:52 PM, Tomas Mraz wrote: > > > > After looking at the actual sources - it shouldn't be in the account > > stage either. However this means it won't work correctly for some PAM > > clients which doesn't call pam_setcred. > > As I wrote, auth is actually fine! Yes, it is, however this doesn't mean that it will work correctly for programs using PAM which don't call pam_setcred. -- Tomas Mraz From markmc at redhat.com Wed Jul 13 13:45:28 2005 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 13 Jul 2005 14:45:28 +0100 Subject: Icons and menus In-Reply-To: <20050712192525.7a55a0a3@python2> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> <1121167399.6273.52.camel@blaa> <20050712133059.10719ec1@python2> <1121177928.6273.89.camel@blaa> <20050712192525.7a55a0a3@python2> Message-ID: <1121262328.4729.76.camel@blaa> Hi, On Tue, 2005-07-12 at 19:25 +0200, Matthias Saou wrote: > Mark McLoughlin wrote : > > > Hi, > > FWIW, it sounds like it'll be fixed in gtk+ by ignoring icon caches > > which aren't accompanied by and index.theme file > > (like /usr/share/pixmaps) and by making gtk-update-icon-cache not > > generate an icon cache where an index.theme file doesn't exist. See: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=310131 > > Probably a good thing. Still : > > The bug reported initially mentioned doesn't seem to necessarily be caused > by an icon cache being present. A minute ago, I ran "yum install > flumotion", and the new entry in my GNOME menu doesn't show any icon. The > desktop file seems fine and the /usr/share/pixmaps/flumotion.png file is > present. > > $ ls /usr/share/pixmaps/*cache* > ls: /usr/share/pixmaps/*cache*: No such file or directory Good call. All my hand-waving and conjecturing was total sheep manure then :-) It turned out to be a pretty straightforward bug in GtkIconTheme. See: http://bugzilla.gnome.org/show_bug.cgi?id=310221 Cheers, Mark. From tmraz at redhat.com Wed Jul 13 13:50:17 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 13 Jul 2005 15:50:17 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D5108F.502@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> <42D50AA2.10004@linux-kernel.at> <1121258935.5812.73.camel@perun.redhat.usu> <42D5108F.502@linux-kernel.at> Message-ID: <1121262618.5812.87.camel@perun.redhat.usu> On Wed, 2005-07-13 at 15:01 +0200, Oliver Falk wrote: > Tomas, what do you think, should a package uninstall check for entries > in /etc/pam.d/* and remove it? > > Because if you have configured it and at some time want to remove it, it > could happen: > > Jul 13 14:59:05 moon sshd[20970]: PAM unable to > dlopen(/lib/security/pam_abl.so) > Jul 13 14:59:05 moon sshd[20970]: PAM [dlerror: > /lib/security/pam_abl.so: cannot open shared object file: No such file > or directory] > Jul 13 14:59:05 moon sshd[20970]: PAM adding faulty module: > /lib/security/pam_abl.so > > :-/ Package uninstall shouldn't mess with /etc/pam.d/* files. (Except of package's owned files of course.) Administrator must know that rpm -e some_random_pam_module package can disable his system access if he has it in system_auth and he must remove it from the system_auth before uninstalling. > > And maybe it should also %ghost /var/lib/abl/hosts.db and users.db, so > it get's removed properly at uninstall... This is debatable - the package of a database system shouldn't remove your databases created using this system either. However this is a very special kind of a database. -- Tomas Mraz From rc040203 at freenet.de Wed Jul 13 13:53:05 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jul 2005 15:53:05 +0200 Subject: Request for review: perl-Want In-Reply-To: <42D519A8.40908@linux-kernel.at> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> <42D512C5.4060507@linux-kernel.at> <1121260996.11257.22.camel@mccallum.corsepiu.local> <42D519A8.40908@linux-kernel.at> Message-ID: <1121262786.11257.28.camel@mccallum.corsepiu.local> On Wed, 2005-07-13 at 15:39 +0200, Oliver Falk wrote: > On 07/13/2005 03:23 PM, Ralf Corsepius wrote: > > On Wed, 2005-07-13 at 15:10 +0200, Oliver Falk wrote: > > > >>owners.list doesn't show you as owner for perl-Want. Please don't forget > >>to add it. > > > > You are barking up the wrong tree: > > * The perl-Want (added 05-07-01) module predates owners.list (added > > 05-07-11). > > Yes, that's correct, but perl-Want was never added to the owners.list > and also there never was a request on BugzillAdmin, afaik. > > > * I don't recall having seen any formal "call for adding yourself to > > owners.list" nor can I find any trace of owners.list on the wiki. > > http://fedoraproject.org/wiki/Extras/BugzillaAdmin > https://www.redhat.com/archives/fedora-maintainers/2005-July/msg00030.html C'mon ... Today is Wednesday, the announcement had been sent Monday evening of my time zone (CEST) and had been pending unread in my mail queue. ... you seem to forget that people sometimes are busy with other tasks and read email selectively :( Ralf From alex at dalloz.de Wed Jul 13 13:57:36 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 15:57:36 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D50C30.9090602@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <42D50C30.9090602@linux-kernel.at> Message-ID: <1121263056.1574.253.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Oliver Falk um 14:42: > >>E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so > > > > Where is that error triggered from? > > I guess it comes from the %description section. Thats the only place where the path appears. So the error goes away when moving the instructions from %description and putting them into README.Fedora %docs file. > Oliver Thanks for comments. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From oliver at linux-kernel.at Wed Jul 13 14:05:55 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:05:55 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121262618.5812.87.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121257427.5812.71.camel@perun.redhat.usu> <42D50AA2.10004@linux-kernel.at> <1121258935.5812.73.camel@perun.redhat.usu> <42D5108F.502@linux-kernel.at> <1121262618.5812.87.camel@perun.redhat.usu> Message-ID: <42D51FC3.1060702@linux-kernel.at> On 07/13/2005 03:50 PM, Tomas Mraz wrote: > On Wed, 2005-07-13 at 15:01 +0200, Oliver Falk wrote: >>Tomas, what do you think, should a package uninstall check for entries >>in /etc/pam.d/* and remove it? >> >>Because if you have configured it and at some time want to remove it, it >>could happen: [ ... ] > Package uninstall shouldn't mess with /etc/pam.d/* files. (Except of > package's owned files of course.) Administrator must know that rpm -e > some_random_pam_module package can disable his system access if he has > it in system_auth and he must remove it from the system_auth before > uninstalling. Sure, a sysadmin should know about that and _I_ do - I just wanted to post you an example, of course. I just believe that this will - sooner or later - be a Bugzilla entry. :-/ Messing around with configfiles using sed, awk, whatever never is a good idea - that's also my meaning (even if we allready do with eg. /etc/shells for example). But I'm thinking about 'the not so real and good sysadmins'... >>And maybe it should also %ghost /var/lib/abl/hosts.db and users.db, so >>it get's removed properly at uninstall... > > This is debatable - the package of a database system shouldn't remove > your databases created using this system either. However this is a very > special kind of a database. OK, then I leave it for the rpm maintainer to decide, if he want's to remove it or not... I don't mind any way... Best, Oliver From ermeyers at adelphia.net Wed Jul 13 14:07:26 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Wed, 13 Jul 2005 10:07:26 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507131007.47065.ermeyers@adelphia.net> I'm a new participant in fedora-extras, and I initially brought up this issue on the fedora-extras mailing list. Review: 1. Why does it say 22 groups, when only 20 groups are listed? 2. Why are 1031 of 1251 packages in __nogroup__? There was a good response to my inquiry, and I watched the discussions between the more experienced members of the group. I'm wondering what is going on now with the solution process, as an outsider. I'm willing to contribute, when I can be of service. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Wed Jul 13 14:09:27 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:09:27 +0200 Subject: Request for review: perl-Want In-Reply-To: <1121262786.11257.28.camel@mccallum.corsepiu.local> References: <1120208445.3741.127.camel@mccallum.corsepiu.local> <42C50C4C.3060001@linux-kernel.at> <1120211140.3741.139.camel@mccallum.corsepiu.local> <42C51CC8.4020309@linux-kernel.at> <1120215631.3741.172.camel@mccallum.corsepiu.local> <42D512C5.4060507@linux-kernel.at> <1121260996.11257.22.camel@mccallum.corsepiu.local> <42D519A8.40908@linux-kernel.at> <1121262786.11257.28.camel@mccallum.corsepiu.local> Message-ID: <42D52097.1010309@linux-kernel.at> On 07/13/2005 03:53 PM, Ralf Corsepius wrote: > On Wed, 2005-07-13 at 15:39 +0200, Oliver Falk wrote: >>On 07/13/2005 03:23 PM, Ralf Corsepius wrote: >>>On Wed, 2005-07-13 at 15:10 +0200, Oliver Falk wrote: >>> >>>>owners.list doesn't show you as owner for perl-Want. Please don't forget >>>>to add it. >>> >>>You are barking up the wrong tree: >>>* The perl-Want (added 05-07-01) module predates owners.list (added >>>05-07-11). >> >>Yes, that's correct, but perl-Want was never added to the owners.list >>and also there never was a request on BugzillAdmin, afaik. >> >> >>>* I don't recall having seen any formal "call for adding yourself to >>>owners.list" nor can I find any trace of owners.list on the wiki. >> >>http://fedoraproject.org/wiki/Extras/BugzillaAdmin >>https://www.redhat.com/archives/fedora-maintainers/2005-July/msg00030.html > > > C'mon ... Today is Wednesday, the announcement had been sent Monday > evening of my time zone (CEST) and had been pending unread in my mail > queue. > > ... you seem to forget that people sometimes are busy with other tasks > and read email selectively :( No, I'm not forgeting, that people have other things to do as well - we all have. My business also is not: Fedora Extras Mailinglist Reader/Writer. :-) I just wanted to inform you about this, in case you havn't seen the mail. A _just_to_be_sure_he_will_not_miss_this_information_mail_while_I_was_checking_the_owners_list_-mail. :-) Best, Oliver From oliver at linux-kernel.at Wed Jul 13 14:11:12 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:11:12 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121263056.1574.253.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <42D50C30.9090602@linux-kernel.at> <1121263056.1574.253.camel@serendipity.dogma.lan> Message-ID: <42D52100.1080809@linux-kernel.at> On 07/13/2005 03:57 PM, Alexander Dalloz wrote: > Am Mi, den 13.07.2005 schrieb Oliver Falk um 14:42: >>>>E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so >>> >>>Where is that error triggered from? >> >>I guess it comes from the %description section. > > Thats the only place where the path appears. So the error goes away when > moving the instructions from %description and putting them into > README.Fedora %docs file. I guess so. > Thanks for comments. U r welcome. Let us see the new release for further review. :-) Best, Oliver From alex at dalloz.de Wed Jul 13 14:18:30 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 16:18:30 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050713143128.789b77f6.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> Message-ID: <1121264309.1574.275.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Michael Schwendt um 14:31: > > That leads me directly to the question: is it necessary to test software > > builds on FC4 with it's latest gcc? > > "Yes, of course!" to the latter question. Ok, will then have to freshly install a build environment based on FC4. > > > Specfile: > > > * Release should be 1%{?dist} > > > > Ok, so the dist tag seems to be mandatory, other than the wiki says. > > No, it isn't. Hm, for 2 rpms without dist tag set I got for both the feedback to set it. I thought at least for the keychain rpm, which just puts the shell script and man page into rpm the dist tag does not make much sense. For packages build against specific distribution version libs I think it makes sense to have an "indicator" like the dist tag in the package filename. A different question, but too regarding package naming. The pam_abl source code tarball is named by it's author pam_abl-20050110-0.2.2.tar.gz I initially thought it would be proper to set %{name} -> pam_abl %{version} -> 0.2.2 %{release} -> 20050110 Using the dist tag means that wherever %{release} should be used I instead have to use "20050110", like in Source0 or BuildRoot. I am on the right path? Another issue with the %{release} is the way how to increase it for reflecting rpm changes. What would be the proper choice for %{release}? %{release} -> 20050110-1%{?dist} In this way? Or better to omit the date value and using a self chosen release number? What's the recommended way? > > > E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so > > > > Where is that error triggered from? > > rpmlint examining your PAM file. So, like Oliver guesses, I think it must be triggered by the path mentioned in the %description section. > On x86_64, PAM modules are stored in /lib64/security/..., so it is > a mistake to hardcode the path. Just put "pam_abl.so" there. I think I took care for this. Regards Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From caillon at redhat.com Wed Jul 13 14:31:28 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 13 Jul 2005 10:31:28 -0400 Subject: Buildsys In-Reply-To: <42D50DC3.8060609@linux-kernel.at> References: <42D50DC3.8060609@linux-kernel.at> Message-ID: <42D525C0.7030606@redhat.com> On 07/13/2005 08:49 AM, Oliver Falk wrote: > Hi! > > The buildsys is still down, is it? > > Best, > Oliver I would assume so until further notice, which would probably be posted to fedora-maintainers. From paul at city-fan.org Wed Jul 13 14:32:51 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 13 Jul 2005 15:32:51 +0100 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121264309.1574.275.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> <1121264309.1574.275.camel@serendipity.dogma.lan> Message-ID: <42D52613.3090809@city-fan.org> Alexander Dalloz wrote: > Am Mi, den 13.07.2005 schrieb Michael Schwendt um 14:31: > > >>>That leads me directly to the question: is it necessary to test software >>>builds on FC4 with it's latest gcc? >> >>"Yes, of course!" to the latter question. > > > Ok, will then have to freshly install a build environment based on FC4. > > >>>>Specfile: >>>>* Release should be 1%{?dist} >>> >>>Ok, so the dist tag seems to be mandatory, other than the wiki says. >> >>No, it isn't. > > > Hm, for 2 rpms without dist tag set I got for both the feedback to set > it. I thought at least for the keychain rpm, which just puts the shell > script and man page into rpm the dist tag does not make much sense. For > packages build against specific distribution version libs I think it > makes sense to have an "indicator" like the dist tag in the package > filename. The requirement is to have the epoch-version-release for later distributions to be "later" than the epoch-version-release for earlier distributions, so that upgrades pick up the right package. The dist tag provides a convenient way of providing for this whilst being able to use the same spec file for each distribution. However, you could assign higher release tags for later distributions and that would satisfy the requirement too. > A different question, but too regarding package naming. The pam_abl > source code tarball is named by it's author > > pam_abl-20050110-0.2.2.tar.gz > > I initially thought it would be proper to set > > %{name} -> pam_abl > %{version} -> 0.2.2 > %{release} -> 20050110 Does upstream change both the date part and the version part when producing a new release? If so, I'd be inclined to skip the (IMHO ugly) date. > Using the dist tag means that wherever %{release} should be used I > instead have to use "20050110", like in Source0 or BuildRoot. I am on > the right path? Yes, that would happen. You could do this though: %{name} -> pam_abl %{version} -> 0.2.2 %{reldate} -> 20050110 %{release} -> %{reldate}%{?dist} Source0: http://host/path/to/pam_abl-%{reldate}-%{version}.tar.gz > Another issue with the %{release} is the way how to increase it for > reflecting rpm changes. What would be the proper choice for %{release}? > > %{release} -> 20050110-1%{?dist} Better to use "." than "-" there I think. > In this way? Or better to omit the date value and using a self chosen > release number? What's the recommended way? I'd do that as long as upstream isn't in the habit of releasing tarballs with a new date but the same version number. Paul. From oliver at linux-kernel.at Wed Jul 13 14:33:03 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:33:03 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121264309.1574.275.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> <1121264309.1574.275.camel@serendipity.dogma.lan> Message-ID: <42D5261F.9070401@linux-kernel.at> On 07/13/2005 04:18 PM, Alexander Dalloz wrote: > Am Mi, den 13.07.2005 schrieb Michael Schwendt um 14:31: [ ...] >>>>Specfile: >>>>* Release should be 1%{?dist} >>> >>>Ok, so the dist tag seems to be mandatory, other than the wiki says. >> >>No, it isn't. > > Hm, for 2 rpms without dist tag set I got for both the feedback to set > it. I thought at least for the keychain rpm, which just puts the shell > script and man page into rpm the dist tag does not make much sense. For > packages build against specific distribution version libs I think it > makes sense to have an "indicator" like the dist tag in the package > filename. It's main purpose, yes, is to indicate for which distribution the package is meant for and even for rpms which just install shell-scripts and manpages, it's good to know, that the package *is meant for distribution X*, since if I would be some dummy user, I can - more or less - believe, that the package *will work* on this distribution. :-) > A different question, but too regarding package naming. The pam_abl > source code tarball is named by it's author > > pam_abl-20050110-0.2.2.tar.gz > > I initially thought it would be proper to set > > %{name} -> pam_abl > %{version} -> 0.2.2 > %{release} -> 20050110 > > Using the dist tag means that wherever %{release} should be used I > instead have to use "20050110", like in Source0 or BuildRoot. I am on > the right path? > Another issue with the %{release} is the way how to increase it for > reflecting rpm changes. What would be the proper choice for %{release}? > > %{release} -> 20050110-1%{?dist} > > In this way? Or better to omit the date value and using a self chosen > release number? What's the recommended way? If the date isn't really part of the real version, omit it. If the date would be the version, because the guy does release a new version every day (who the hell does this?), it would be ok, to use the date as version - I think. So use *you* rpm release for the release tag... >>>>E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so >>> >>>Where is that error triggered from? >> >>rpmlint examining your PAM file. > > So, like Oliver guesses, I think it must be triggered by the path > mentioned in the %description section. Hope so. :-) >>On x86_64, PAM modules are stored in /lib64/security/..., so it is >>a mistake to hardcode the path. Just put "pam_abl.so" there. > > I think I took care for this. AFAIK, you did. Best, Oliver From skvidal at phy.duke.edu Wed Jul 13 14:35:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Jul 2005 10:35:35 -0400 Subject: Buildsys In-Reply-To: <42D50DC3.8060609@linux-kernel.at> References: <42D50DC3.8060609@linux-kernel.at> Message-ID: <1121265335.7466.21.camel@cutter> On Wed, 2005-07-13 at 14:49 +0200, Oliver Falk wrote: > Hi! > > The buildsys is still down, is it? yes. -sv From skvidal at phy.duke.edu Wed Jul 13 14:36:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Jul 2005 10:36:26 -0400 Subject: Buildsys In-Reply-To: <42D525C0.7030606@redhat.com> References: <42D50DC3.8060609@linux-kernel.at> <42D525C0.7030606@redhat.com> Message-ID: <1121265386.7466.23.camel@cutter> On Wed, 2005-07-13 at 10:31 -0400, Christopher Aillon wrote: > On 07/13/2005 08:49 AM, Oliver Falk wrote: > > > Hi! > > > > The buildsys is still down, is it? > > > > Best, > > Oliver > > I would assume so until further notice, which would probably be posted > to fedora-maintainers. and to fedora-extras. Dan got through one of the problems last night and now we just need to import the set of people who can add jobs to the system then enable it. There are some other tests to do but that's what is going on right now. -sv From alex at dalloz.de Wed Jul 13 14:36:26 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 16:36:26 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D52100.1080809@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <42D50C30.9090602@linux-kernel.at> <1121263056.1574.253.camel@serendipity.dogma.lan> <42D52100.1080809@linux-kernel.at> Message-ID: <1121265386.1574.285.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Oliver Falk um 16:11: > U r welcome. Let us see the new release for further review. :-) > Oliver I think what Tomas Mraz replied "Yes, it is, however this doesn't mean that it will work correctly for programs using PAM which don't call pam_setcred." is actually a show stopper for the RPM. At least I understand it that way. From my point of view not any add-in PAM module should break PAM in any way. So if pam_abl breaks things under specific conditions I would withdraw my suggestion / review request. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From oliver at linux-kernel.at Wed Jul 13 14:38:58 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:38:58 +0200 Subject: Buildsys In-Reply-To: <42D525C0.7030606@redhat.com> References: <42D50DC3.8060609@linux-kernel.at> <42D525C0.7030606@redhat.com> Message-ID: <42D52782.7060201@linux-kernel.at> On 07/13/2005 04:31 PM, Christopher Aillon wrote: > On 07/13/2005 08:49 AM, Oliver Falk wrote: > >> Hi! >> >> The buildsys is still down, is it? >> > I would assume so until further notice, which would probably be posted > to fedora-maintainers. OK. I just wanted to know if I might have missed some mail... Best, Oliver From oliver at linux-kernel.at Wed Jul 13 14:42:06 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:42:06 +0200 Subject: Buildsys In-Reply-To: <1121265386.7466.23.camel@cutter> References: <42D50DC3.8060609@linux-kernel.at> <42D525C0.7030606@redhat.com> <1121265386.7466.23.camel@cutter> Message-ID: <42D5283E.2030500@linux-kernel.at> On 07/13/2005 04:36 PM, seth vidal wrote: > On Wed, 2005-07-13 at 10:31 -0400, Christopher Aillon wrote: > >>On 07/13/2005 08:49 AM, Oliver Falk wrote: >> >> >>>Hi! >>> >>>The buildsys is still down, is it? >>> >>I would assume so until further notice, which would probably be posted >>to fedora-maintainers. > > > and to fedora-extras. > > Dan got through one of the problems last night and now we just need to > import the set of people who can add jobs to the system then enable it. > There are some other tests to do but that's what is going on right now. Fine. Good to hear some news and to know, that you are still alive and working on it. :-) Best, Oliver From alex at dalloz.de Wed Jul 13 14:42:20 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 16:42:20 +0200 Subject: Request for review: keychain In-Reply-To: <1121184553.22425.35.camel@localhost.localdomain> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> <1121139082.1574.182.camel@serendipity.dogma.lan> <1121184553.22425.35.camel@localhost.localdomain> Message-ID: <1121265739.1574.291.camel@serendipity.dogma.lan> Am Di, den 12.07.2005 schrieb Ville Skytt? um 18:09: > > http://www.uni-x.org/keychain.spec > > http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm > > Bumping the release when you make updates and adding a changelog entry > would be useful for tracking purposes. My fault, noted. > Anyway, I have a local package of this too, here's some cosmetic stuff > that mine has but yours doesn't (maybe yet? ;)): > - In %prep: sed -i -e 's|/usr/ucb:||' keychain Do you think this is necessary? From my experience the non existing path element (on Fedora) does no harm (no warnings, error messages or else). On the other side removing it inside the keychain script will not break anything on Fedora. I will include the %prep step. > - A docs patch, see attachment. (The reason for the "which" is that > home dirs may be shared accross hosts, and it's possible that all of > them don't have keychain installed.) I feel the changes to the man page are good. So thanks for recommendation, I will apply the patch. > The reason why I hadn't submitted this package to Extras yet is its > annoying interaction with the ssh-agent launched by FC's gdm. I use gdm > and KDE, and have this in my ~/.bash_profile: > > which keychain &>/dev/null && keychain -q id_dsa > [[ -f $HOME/.keychain/$HOSTNAME-sh ]] && \ > source $HOME/.keychain/$HOSTNAME-sh > > When logging in through gdm, while KDE starts up, I get a ssh-askpass > dialog prompting for the passphrase, which is ok. Then, I type the > passphrase in, it's accepted and life seems good. But when I start up a > Konsole session, ssh'ing somewhere results in the passphrase query. It > seems that there are actually two ssh-agents launched, and the > passphrases I typed at KDE startup ended up in the "wrong" one. Very > annoying, and I haven't found a solution yet. Ideas? That indicates that testing with a KDE environment is necessary. I only run Gnome and never had such an issue with keychain. Thanks! Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From skvidal at phy.duke.edu Wed Jul 13 14:45:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Jul 2005 10:45:20 -0400 Subject: Buildsys In-Reply-To: <42D5283E.2030500@linux-kernel.at> References: <42D50DC3.8060609@linux-kernel.at> <42D525C0.7030606@redhat.com> <1121265386.7466.23.camel@cutter> <42D5283E.2030500@linux-kernel.at> Message-ID: <1121265920.7466.26.camel@cutter> On Wed, 2005-07-13 at 16:42 +0200, Oliver Falk wrote: > On 07/13/2005 04:36 PM, seth vidal wrote: > > On Wed, 2005-07-13 at 10:31 -0400, Christopher Aillon wrote: > > > >>On 07/13/2005 08:49 AM, Oliver Falk wrote: > >> > >> > >>>Hi! > >>> > >>>The buildsys is still down, is it? > >>> > >>I would assume so until further notice, which would probably be posted > >>to fedora-maintainers. > > > > > > and to fedora-extras. > > > > Dan got through one of the problems last night and now we just need to > > import the set of people who can add jobs to the system then enable it. > > There are some other tests to do but that's what is going on right now. > > Fine. Good to hear some news and to know, that you are still alive and > working on it. :-) > I posted to this list and -maintainers about the status of it on monday So I'm still alive. -sv From oliver at linux-kernel.at Wed Jul 13 14:45:06 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:45:06 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121265386.1574.285.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <42D50C30.9090602@linux-kernel.at> <1121263056.1574.253.camel@serendipity.dogma.lan> <42D52100.1080809@linux-kernel.at> <1121265386.1574.285.camel@serendipity.dogma.lan> Message-ID: <42D528F2.7040803@linux-kernel.at> On 07/13/2005 04:36 PM, Alexander Dalloz wrote: > Am Mi, den 13.07.2005 schrieb Oliver Falk um 16:11: > >>U r welcome. Let us see the new release for further review. :-) > > I think what Tomas Mraz replied > > "Yes, it is, however this doesn't mean that it will work correctly for > programs using PAM which don't call pam_setcred." > > is actually a show stopper for the RPM. At least I understand it that > way. From my point of view not any add-in PAM module should break PAM in > any way. So if pam_abl breaks things under specific conditions I would > withdraw my suggestion / review request. AFAIK. It wouldn't *break* anything, it would just not work for those programs. Best, Oliver From alex at dalloz.de Wed Jul 13 14:48:28 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 16:48:28 +0200 Subject: Request for review: keychain In-Reply-To: <3ab624bd050711205432e6650e@mail.gmail.com> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> Message-ID: <1121266108.1574.298.camel@serendipity.dogma.lan> Am Di, den 12.07.2005 schrieb Chip Turner um 5:54: > It would be nicer to have some sort of opt-in, perhaps in the form of > ~/.keychainrc, which, if present, causes it to be source'd and then, > if set, use an environment variable KEYS to list the keys the user > wants, otherwise default to id_dsa. This way a user just specifies > their keys that feed the command line (and perhaps other command line > options such as timeout). > > Chip I think it makes sense regarding ease of use, to have a mechanism which allows the user to opt-in keychaining easily. Thanks for that suggestion Chip, Ed and Ville. I kindly request to review following bah script: http://www.uni-x.org/keychain.sh.txt I plan to let the keychain rpm place keychain.{sh,csh} - csh needs to be done (help would be welcome as I am a bash user) - into /etc/profile.d/. It will then create a ~/.keychainrc file if none exists already. The user is able to adjust keychain behaviour through that file then. Any kind of critics and of course corrections are welcome. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 13 14:51:04 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jul 2005 16:51:04 +0200 Subject: Icons and menus In-Reply-To: <1121262328.4729.76.camel@blaa> References: <1120635097.15736.264.camel@laurel.intra.city-fan.org> <1121167399.6273.52.camel@blaa> <20050712133059.10719ec1@python2> <1121177928.6273.89.camel@blaa> <20050712192525.7a55a0a3@python2> <1121262328.4729.76.camel@blaa> Message-ID: <20050713165104.5f631f97@python2> Mark McLoughlin wrote : > It turned out to be a pretty straightforward bug in GtkIconTheme. See: > > http://bugzilla.gnome.org/show_bug.cgi?id=310221 So I'm not totally insane (yet)! :-) Thanks a lot for tracking this one down and fixing it! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.48 0.51 0.61 From oliver at linux-kernel.at Wed Jul 13 14:53:10 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 16:53:10 +0200 Subject: Buildsys In-Reply-To: <1121265920.7466.26.camel@cutter> References: <42D50DC3.8060609@linux-kernel.at> <42D525C0.7030606@redhat.com> <1121265386.7466.23.camel@cutter> <42D5283E.2030500@linux-kernel.at> <1121265920.7466.26.camel@cutter> Message-ID: <42D52AD6.4020302@linux-kernel.at> On 07/13/2005 04:45 PM, seth vidal wrote: > On Wed, 2005-07-13 at 16:42 +0200, Oliver Falk wrote: >>On 07/13/2005 04:36 PM, seth vidal wrote: >>>On Wed, 2005-07-13 at 10:31 -0400, Christopher Aillon wrote: >>>>On 07/13/2005 08:49 AM, Oliver Falk wrote: >>>>>The buildsys is still down, is it? >>>>> >>>>I would assume so until further notice, which would probably be posted >>>>to fedora-maintainers. >>> >>>and to fedora-extras. >>> >>>Dan got through one of the problems last night and now we just need to >>>import the set of people who can add jobs to the system then enable it. >>>There are some other tests to do but that's what is going on right now. >> >>Fine. Good to hear some news and to know, that you are still alive and >>working on it. :-) > > I posted to this list and -maintainers about the status of it on monday > So I'm still alive. Yes, this was on Monday, but noone said, you haven't been bitten by the python-snake and died, while trying to bugfix the buildsys. :-) Seth, I'm just jokin', let's keep smiling :-) Best, Oliver From skvidal at phy.duke.edu Wed Jul 13 14:55:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Jul 2005 10:55:49 -0400 Subject: Buildsys In-Reply-To: <42D52AD6.4020302@linux-kernel.at> References: <42D50DC3.8060609@linux-kernel.at> <42D525C0.7030606@redhat.com> <1121265386.7466.23.camel@cutter> <42D5283E.2030500@linux-kernel.at> <1121265920.7466.26.camel@cutter> <42D52AD6.4020302@linux-kernel.at> Message-ID: <1121266550.7466.30.camel@cutter> > Yes, this was on Monday, but noone said, you haven't been bitten by the > python-snake and died, while trying to bugfix the buildsys. :-) > > Seth, I'm just jokin', let's keep smiling :-) > Dan williams has been doing all the heavy work. I've mostly just been reporting bugs to him and annoying him :) So when things are working, thank him, not me, for getting it all set. He really deserves it. -sv From paul at city-fan.org Wed Jul 13 15:08:34 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 13 Jul 2005 16:08:34 +0100 Subject: Request for review: keychain In-Reply-To: <1121266108.1574.298.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> <1121266108.1574.298.camel@serendipity.dogma.lan> Message-ID: <42D52E72.30306@city-fan.org> Alexander Dalloz wrote: > Am Di, den 12.07.2005 schrieb Chip Turner um 5:54: > > >>It would be nicer to have some sort of opt-in, perhaps in the form of >>~/.keychainrc, which, if present, causes it to be source'd and then, >>if set, use an environment variable KEYS to list the keys the user >>wants, otherwise default to id_dsa. This way a user just specifies >>their keys that feed the command line (and perhaps other command line >>options such as timeout). >> >>Chip > > > I think it makes sense regarding ease of use, to have a mechanism which > allows the user to opt-in keychaining easily. Thanks for that suggestion > Chip, Ed and Ville. > > I kindly request to review following bah script: > > http://www.uni-x.org/keychain.sh.txt > > I plan to let the keychain rpm place keychain.{sh,csh} - csh needs to be > done (help would be welcome as I am a bash user) - into /etc/profile.d/. > It will then create a ~/.keychainrc file if none exists already. The > user is able to adjust keychain behaviour through that file then. > > Any kind of critics and of course corrections are welcome. This is quite a complicated script to maintain in two different formats, particularly since it's sourcing a sh-format ~/.keychainrc file. Would it not be possible to put this in a helper script in /usr/bin (or wherever's convenient) and then call it from /etc/profile.d/keychain.{sh,csh}, thus making those two scripts much smaller and possibly even identical? I don't see any environment variables being exported, so is it really necessary to "source" all this stuff? Paul. From alex at dalloz.de Wed Jul 13 15:12:42 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 17:12:42 +0200 Subject: Request for review: keychain In-Reply-To: <1121266108.1574.298.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> <1121266108.1574.298.camel@serendipity.dogma.lan> Message-ID: <1121267562.1574.305.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Alexander Dalloz um 16:48: > Am Di, den 12.07.2005 sch > I kindly request to review following bah script: > > http://www.uni-x.org/keychain.sh.txt Gna! Found a very stupid already my own :( line 4: which keychain &>/dev/null || exit 1 is of course a bad idea as it will prevent users from logging in when "keychain" isn't found. As I would like to let the profile script only run when keychain is existing on the host, my suggestion is which keychain &>/dev/null && ( ... ) where the ( ) surround the whole script. Corrected script: http://www.uni-x.org/keychain.sh.2.txt Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From alex at dalloz.de Wed Jul 13 15:25:19 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 17:25:19 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D52613.3090809@city-fan.org> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> <1121264309.1574.275.camel@serendipity.dogma.lan> <42D52613.3090809@city-fan.org> Message-ID: <1121268319.1574.314.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Paul Howarth um 16:32: > Yes, that would happen. You could do this though: > > %{name} -> pam_abl > %{version} -> 0.2.2 > %{reldate} -> 20050110 > %{release} -> %{reldate}%{?dist} > > Source0: http://host/path/to/pam_abl-%{reldate}-%{version}.tar.gz > > > Another issue with the %{release} is the way how to increase it for > > reflecting rpm changes. What would be the proper choice for %{release}? > > > > %{release} -> 20050110-1%{?dist} > > Better to use "." than "-" there I think. Thanks Paul - and Oliver of course too - for your valuable replies. > > In this way? Or better to omit the date value and using a self chosen > > release number? What's the recommended way? > > I'd do that as long as upstream isn't in the habit of releasing tarballs > with a new date but the same version number. I think I will anyway contact the upstream author of pam_abl, informing him about the intention to include his PAM module into Fedora Extras and asking him some things, besides the note about his outdated documentation in his tarball (I refer to the other part of this thread). > Paul. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From bugs.michael at gmx.net Wed Jul 13 15:30:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Jul 2005 17:30:51 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D5261F.9070401@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> <1121264309.1574.275.camel@serendipity.dogma.lan> <42D5261F.9070401@linux-kernel.at> Message-ID: <20050713173051.1f10abef.bugs.michael@gmx.net> On Wed, 13 Jul 2005 16:33:03 +0200, Oliver Falk wrote: > On 07/13/2005 04:18 PM, Alexander Dalloz wrote: > > Am Mi, den 13.07.2005 schrieb Michael Schwendt um 14:31: > [ ...] > >>>>Specfile: > >>>>* Release should be 1%{?dist} > >>> > >>>Ok, so the dist tag seems to be mandatory, other than the wiki says. > >> > >>No, it isn't. > > > > Hm, for 2 rpms without dist tag set I got for both the feedback to set > > it. You are free to ignore such recommendations. I, for instance, would not like to be forced to add %{?dist} for a noarch/data package, which doesn't need a rebuild for the next distribution. > I thought at least for the keychain rpm, which just puts the shell > > script and man page into rpm the dist tag does not make much sense. For > > packages build against specific distribution version libs I think it > > makes sense to have an "indicator" like the dist tag in the package > > filename. > > It's main purpose, yes, is to indicate for which distribution the > package is meant for That's certainly _not_ the main purpose, it's a side-effect of choosing human-readable distribution tags. Its main purpose is in influencing RPM version comparison in a way it is helpful for distribution upgrades and mass-builds of a single src.rpm for multiple distribution versions. From oliver at linux-kernel.at Wed Jul 13 15:29:20 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 17:29:20 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121268319.1574.314.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> <1121264309.1574.275.camel@serendipity.dogma.lan> <42D52613.3090809@city-fan.org> <1121268319.1574.314.camel@serendipity.dogma.lan> Message-ID: <42D53350.9080408@linux-kernel.at> On 07/13/2005 05:25 PM, Alexander Dalloz wrote: > Am Mi, den 13.07.2005 schrieb Paul Howarth um 16:32: > > >>Yes, that would happen. You could do this though: >> >>%{name} -> pam_abl >>%{version} -> 0.2.2 >>%{reldate} -> 20050110 >>%{release} -> %{reldate}%{?dist} >> >>Source0: http://host/path/to/pam_abl-%{reldate}-%{version}.tar.gz >> >> >>>Another issue with the %{release} is the way how to increase it for >>>reflecting rpm changes. What would be the proper choice for %{release}? >>> >>>%{release} -> 20050110-1%{?dist} >> >>Better to use "." than "-" there I think. > > > Thanks Paul - and Oliver of course too - for your valuable replies. > > >>>In this way? Or better to omit the date value and using a self chosen >>>release number? What's the recommended way? >> >>I'd do that as long as upstream isn't in the habit of releasing tarballs >>with a new date but the same version number. > > > I think I will anyway contact the upstream author of pam_abl, informing > him about the intention to include his PAM module into Fedora Extras and > asking him some things, besides the note about his outdated > documentation in his tarball (I refer to the other part of this thread). This - of course - is a good idea! Best, Oliver From oliver at linux-kernel.at Wed Jul 13 15:33:11 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 13 Jul 2005 17:33:11 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050713173051.1f10abef.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D37893.9030902@linux-kernel.at> <1121255209.1574.219.camel@serendipity.dogma.lan> <20050713143128.789b77f6.bugs.michael@gmx.net> <1121264309.1574.275.camel@serendipity.dogma.lan> <42D5261F.9070401@linux-kernel.at> <20050713173051.1f10abef.bugs.michael@gmx.net> Message-ID: <42D53437.3080500@linux-kernel.at> On 07/13/2005 05:30 PM, Michael Schwendt wrote: > On Wed, 13 Jul 2005 16:33:03 +0200, Oliver Falk wrote: > > >>On 07/13/2005 04:18 PM, Alexander Dalloz wrote: >> >>>Am Mi, den 13.07.2005 schrieb Michael Schwendt um 14:31: >> >>[ ...] >> >>>>>>Specfile: >>>>>>* Release should be 1%{?dist} >>>>> >>>>>Ok, so the dist tag seems to be mandatory, other than the wiki says. >>>> >>>>No, it isn't. >>> >>>Hm, for 2 rpms without dist tag set I got for both the feedback to set >>>it. > > > You are free to ignore such recommendations. I, for instance, would not > like to be forced to add %{?dist} for a noarch/data package, which doesn't > need a rebuild for the next distribution. > > >>I thought at least for the keychain rpm, which just puts the shell >> >>>script and man page into rpm the dist tag does not make much sense. For >>>packages build against specific distribution version libs I think it >>>makes sense to have an "indicator" like the dist tag in the package >>>filename. >> >>It's main purpose, yes, is to indicate for which distribution the >>package is meant for > > That's certainly _not_ the main purpose, it's a side-effect of choosing > human-readable distribution tags. Its main purpose is in influencing > RPM version comparison in a way it is helpful for distribution upgrades > and mass-builds of a single src.rpm for multiple distribution versions. With 'indicate for which distribution', I didn't mean indication for humans, but for the package manager (rpm). :-) You got me wrong, but it was my mistake, I wasn't 'correct' enough. Best, Oliver From ed at eh3.com Wed Jul 13 15:49:21 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 13 Jul 2005 11:49:21 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507131007.47065.ermeyers@adelphia.net> References: <200507131007.47065.ermeyers@adelphia.net> Message-ID: <1121269762.15220.132.camel@ernie> On Wed, 2005-07-13 at 10:07 -0400, Eric R. Meyers wrote: > I'm a new participant in fedora-extras, and I initially brought up this issue > on the fedora-extras mailing list. > > Review: > 1. Why does it say 22 groups, when only 20 groups are listed? > 2. Why are 1031 of 1251 packages in __nogroup__? > > There was a good response to my inquiry, and I watched the discussions between > the more experienced members of the group. I'm wondering what is going on > now with the solution process, as an outsider. > > I'm willing to contribute, when I can be of service. Hi Eric & others, I've been following this thread which started at: https://www.redhat.com/archives/fedora-extras-list/2005- July/msg00436.html and am trying to understand it. Heres my summary to-date and *please* correct me if I've mis-understood anything: 1) most folks (eg. Katz, Spaleta) don't want to use the group tags that are located in the spec files and apparently for good reasons -- it just doesn't scale 2) most folks do like the idea of having a small number of people maintain the comps.xml file but they're too busy to work on it now and much too busy to take the lead and write helpful make-driven bits to simplify the process by which package maintainers could "nominate" their package(s) for inclusion into one or more group(s) 3) currently, all one needs is a text editor and a willingness to sort through the packages and edit "comps.xml" to improve the current situation -- writing some more automated bits as described in (2) could be evolved over time So, if Jef and Eric (and perhaps others) were given CVS access to edit the comps-extras package: http://cvs.fedora.redhat.com/viewcvs/rpms/comps-extras/ then they could help. Right? But, it looks like that package is currently in "core" so only Red Hat folks can edit it. If so, shouldn't it be moved out to Extras? Or, could Extras folks somehow have the ability to edit just the content delivered by that package? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From symbiont at berlios.de Wed Jul 13 15:53:05 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 13 Jul 2005 23:53:05 +0800 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050713173051.1f10abef.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D5261F.9070401@linux-kernel.at> <20050713173051.1f10abef.bugs.michael@gmx.net> Message-ID: <200507132353.05654.symbiont@berlios.de> On Wednesday 13 July 2005 23:30, Michael Schwendt wrote: > You are free to ignore such recommendations. I, for instance, would > not like to be forced to add %{?dist} for a noarch/data package, > which doesn't need a rebuild for the next distribution. What about /usr/lib/python2.4/site-packages/foo in FC5 and then /usr/lib/python2.5/site-packages/foo in FC6? Lots of noarchs need rebuild for next distro. Especially those that involve ver-dependent directory structures. -- -jeff From katzj at redhat.com Wed Jul 13 15:55:01 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Jul 2005 11:55:01 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121269762.15220.132.camel@ernie> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> Message-ID: <1121270101.3578.3.camel@bree.local.net> On Wed, 2005-07-13 at 11:49 -0400, Ed Hill wrote: > So, if Jef and Eric (and perhaps others) were given CVS access to edit > the comps-extras package: > > http://cvs.fedora.redhat.com/viewcvs/rpms/comps-extras/ > > then they could help. Right? comps-extras is a misnomer. It's not the comps for extras, it's additional things for dealing with comps. Realistically, if someone volunteers, we can create the repository in /cvs/fedora for the extras comps file and just maintain it there. Jeremy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 13 16:00:09 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jul 2005 18:00:09 +0200 Subject: Request for review: bwm-ng In-Reply-To: <42D50DF5.7020709@linux-kernel.at> References: <42CE7809.3090202@linux-kernel.at> <42D280D6.6040201@linux-kernel.at> <42D50DF5.7020709@linux-kernel.at> Message-ID: <20050713180009.25cfeb09@python2> Oliver Falk wrote : > > > Please review/approve. > > > > Noone saw this, did you? > > Still now answer? :-/ Here's one :-) I'm a little lazy to list all the changes I've made... see the patch. Main remarks : - Source URL wasn't valid anymore - Summary started with "A ..." - You seem to not be friends with tabulations ;-) - Stripping must be avoided to get useful debuginfo packages - You forgot to include the man page - Passing defaults to configure only decreases readability (IMHO) And last, the big blocks of comments which are completely redundant with the spec file delimiter right below (i.e. %description, %prep, %build, %install...) should be avoided since they're not really useful as long as you have proper syntax colouring, and can trigger unwanted side-effects, most notably their inclusion into %pre*/%post* scriplets (although there are none in this particular packages). Please merge in the changes that you like, then I'll review again. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.17 0.40 0.76 -------------- next part -------------- A non-text attachment was scrubbed... Name: bwm-ng.spec.patch Type: text/x-patch Size: 4005 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 13 16:04:07 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jul 2005 18:04:07 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <200507132353.05654.symbiont@berlios.de> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D5261F.9070401@linux-kernel.at> <20050713173051.1f10abef.bugs.michael@gmx.net> <200507132353.05654.symbiont@berlios.de> Message-ID: <20050713180407.16ab680f@python2> Jeff Pitman wrote : > On Wednesday 13 July 2005 23:30, Michael Schwendt wrote: > > You are free to ignore such recommendations. I, for instance, would > > not like to be forced to add %{?dist} for a noarch/data package, > > which doesn't need a rebuild for the next distribution. > > What about /usr/lib/python2.4/site-packages/foo in FC5 and > then /usr/lib/python2.5/site-packages/foo in FC6? > > Lots of noarchs need rebuild for next distro. Especially those that > involve ver-dependent directory structures. I think Micheal was referring to stuff such as game data files, which weigh many megabytes and usually don't need to be rebuilt for the next distribution. So adding %{?dist} to those does seems silly. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.28 0.36 0.65 From gdk at redhat.com Wed Jul 13 16:05:40 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 13 Jul 2005 12:05:40 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121270101.3578.3.camel@bree.local.net> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> Message-ID: I believe that Eric is the volunteer. I believe he's volunteered for this duty 3 or 4 times now, in fact. :) So now the steps to getting it done: 1. Eric, get CVS access. It's documented under "how to be a contributor." 2. Create the repo for comps in /cvs/fedora. Sopwith? Jeremy? 3. Eric, start hacking. Is that pretty much it? --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Wed, 13 Jul 2005, Jeremy Katz wrote: > On Wed, 2005-07-13 at 11:49 -0400, Ed Hill wrote: > > So, if Jef and Eric (and perhaps others) were given CVS access to edit > > the comps-extras package: > > > > http://cvs.fedora.redhat.com/viewcvs/rpms/comps-extras/ > > > > then they could help. Right? > > comps-extras is a misnomer. It's not the comps for extras, it's > additional things for dealing with comps. > > Realistically, if someone volunteers, we can create the repository > in /cvs/fedora for the extras comps file and just maintain it there. > > Jeremy > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From chip.turner at gmail.com Wed Jul 13 16:24:05 2005 From: chip.turner at gmail.com (Chip Turner) Date: Wed, 13 Jul 2005 09:24:05 -0700 Subject: Request for review: keychain In-Reply-To: <1121267562.1574.305.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> <1121266108.1574.298.camel@serendipity.dogma.lan> <1121267562.1574.305.camel@serendipity.dogma.lan> Message-ID: <3ab624bd0507130924669e3625@mail.gmail.com> On 7/13/05, Alexander Dalloz wrote: > Am Mi, den 13.07.2005 schrieb Alexander Dalloz um 16:48: > > Am Di, den 12.07.2005 sch > > > I kindly request to review following bah script: > > > > http://www.uni-x.org/keychain.sh.txt > > Gna! Found a very stupid already my own :( > > line 4: which keychain &>/dev/null || exit 1 > is of course a bad idea as it will prevent users from logging in when > "keychain" isn't found. As I would like to let the profile script only > run when keychain is existing on the host, my suggestion is > > which keychain &>/dev/null && ( > ... ) > > where the ( ) surround the whole script. > > Corrected script: > > http://www.uni-x.org/keychain.sh.2.txt Overall a good start! But, this script is a bit complicated. Some comments: 1) The differentiation between rsa keys, dsa keys, and gpg keys is a bit unnecessary since they all end up on the command line anyway. 2) You can just use 'local FOO=""' instead of FOO="" and then worrying about unsetting FOO. 3) Along with 2, you can have a 'set -u' that will require all vars declared, thus ensuring you don't end up with FOOs that need localing or unsetting that you didn't realize 4) It would be nicer if a user just doing 'touch ~/.keychainrc' would activate it. Creating empty configs for users who don't know anything about keychain (maybe the admin just installed it for herself!) is confusing, especially since it isn't done silently. Basically I'd personally rather it be 'if keychainrc exists, set some defaults that would load all the keys, then source the user's file letting them override our defaults' and not 'require multiple settings in user's config to have the system work properly' 5) creating files in a user's homedir silently is naughty, esp for software they've never ever run. 6) The 'which keychain' is unnecessary since your script is part of the keychain rpm -- one goes with the other :) 7) chmod'ing to 640 is bad if a user has a umask of 077, etc. 8) General scripting rule of thumb: when you nest four if loops deep, something else is probably wrong. Chip -- Chip Turner chip.turner at gmail.com From symbiont at berlios.de Wed Jul 13 16:34:37 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 14 Jul 2005 00:34:37 +0800 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050713180407.16ab680f@python2> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <200507132353.05654.symbiont@berlios.de> <20050713180407.16ab680f@python2> Message-ID: <200507140034.38237.symbiont@berlios.de> On Thursday 14 July 2005 00:04, Matthias Saou wrote: > Jeff Pitman wrote : > > On Wednesday 13 July 2005 23:30, Michael Schwendt wrote: > > > You are free to ignore such recommendations. I, for instance, > > > would not like to be forced to add %{?dist} for a noarch/data > > > package, which doesn't need a rebuild for the next distribution. > > > > What about /usr/lib/python2.4/site-packages/foo in FC5 and > > then /usr/lib/python2.5/site-packages/foo in FC6? > > > > Lots of noarchs need rebuild for next distro. Especially those that > > involve ver-dependent directory structures. > > I think Micheal was referring to stuff such as game data files, which > weigh many megabytes and usually don't need to be rebuilt for the > next distribution. So adding %{?dist} to those does seems silly. Ahh, ok. I just didn't want to see a noarch means no %{?dist} to come out of the discussion. Because lots of noarch do need them. -- -jeff From jpo at di.uminho.pt Wed Jul 13 16:44:22 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Wed, 13 Jul 2005 17:44:22 +0100 Subject: [Fwd: Request for review: libdnet] In-Reply-To: <42CE7705.2090002@linux-kernel.at> References: <42CE7705.2090002@linux-kernel.at> Message-ID: <42D544E6.4010503@di.uminho.pt> Oliver, > SRPM & SPEC: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet Todo list: * use "%setup -q" instead of %setup (-q -> quiet mode) * use "make install DESTDIR=..." instead of %makeinstall * wrong group in the progs subpackage * %post/%postun scripts missing * library (.so ) in the wrong package * don't include the .la file * missing doc files (LICENSE is critical) * don't overuse the %attr macros. There is nothing wrong with the default file permissions * don't use TABs in specfiles * and run rpmlint before submitting a package for review jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: libdnet.spec.patch Type: text/x-patch Size: 1891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Wed Jul 13 17:03:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Jul 2005 13:03:42 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> Message-ID: <1121274222.11215.3.camel@cutter> On Wed, 2005-07-13 at 12:05 -0400, Greg DeKoenigsberg wrote: > I believe that Eric is the volunteer. I believe he's volunteered for this > duty 3 or 4 times now, in fact. :) > > So now the steps to getting it done: > > 1. Eric, get CVS access. It's documented under "how to be a contributor." > 2. Create the repo for comps in /cvs/fedora. Sopwith? Jeremy? > 3. Eric, start hacking. > > Is that pretty much it? I need to add a 'pull comps.xml from cvs' to the extras-push script so it gets updated with any regularity. not a lot of work - just another minor step. -sv From ville.skytta at iki.fi Wed Jul 13 17:17:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 13 Jul 2005 20:17:25 +0300 Subject: Request for review: keychain In-Reply-To: <1121265739.1574.291.camel@serendipity.dogma.lan> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121134236.26750.74.camel@ernie> <1121139082.1574.182.camel@serendipity.dogma.lan> <1121184553.22425.35.camel@localhost.localdomain> <1121265739.1574.291.camel@serendipity.dogma.lan> Message-ID: <1121275045.4170.16.camel@localhost.localdomain> On Wed, 2005-07-13 at 16:42 +0200, Alexander Dalloz wrote: > Am Di, den 12.07.2005 schrieb Ville Skytt? um 18:09: > > Anyway, I have a local package of this too, here's some cosmetic stuff > > that mine has but yours doesn't (maybe yet? ;)): > > - In %prep: sed -i -e 's|/usr/ucb:||' keychain > > Do you think this is necessary? No, I said "cosmetic" :). But it certainly won't hurt either. > > The reason why I hadn't submitted this package to Extras yet is its > > annoying interaction with the ssh-agent launched by FC's gdm. I use gdm > > and KDE, and have this in my ~/.bash_profile: > > > > which keychain &>/dev/null && keychain -q id_dsa > > [[ -f $HOME/.keychain/$HOSTNAME-sh ]] && \ > > source $HOME/.keychain/$HOSTNAME-sh > > > > When logging in through gdm, while KDE starts up, I get a ssh-askpass > > dialog prompting for the passphrase, which is ok. Then, I type the > > passphrase in, it's accepted and life seems good. But when I start up a > > Konsole session, ssh'ing somewhere results in the passphrase query. It > > seems that there are actually two ssh-agents launched, and the > > passphrases I typed at KDE startup ended up in the "wrong" one. Very > > annoying, and I haven't found a solution yet. Ideas? > > That indicates that testing with a KDE environment is necessary. I only > run Gnome and never had such an issue with keychain. I've just tested with GNOME and it exhibits the exact same problem here. From jspaleta at gmail.com Wed Jul 13 18:04:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 13 Jul 2005 14:04:19 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121274222.11215.3.camel@cutter> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <1121274222.11215.3.camel@cutter> Message-ID: <604aa7910507131104553ee8ef@mail.gmail.com> On 7/13/05, seth vidal wrote: > I need to add a 'pull comps.xml from cvs' to the extras-push script so > it gets updated with any regularity. Would there be a need for branch specific comps.xml files since fc3,fc4 and devel have different package collections available in extras? Or is it fine to have one comps.xml file that includes references to packages that aren't in a tree? Would a missing mandatory group member screw up groupinstall commands? Also would it make since for there to be an equivalent to the tag and build request action packages have for the comps.xml, so that your scripted pull gets only a version tagged for consumption instead of some interim version thats being worked on? -jef From skvidal at phy.duke.edu Wed Jul 13 18:10:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Jul 2005 14:10:15 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507131104553ee8ef@mail.gmail.com> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <1121274222.11215.3.camel@cutter> <604aa7910507131104553ee8ef@mail.gmail.com> Message-ID: <1121278215.11215.14.camel@cutter> On Wed, 2005-07-13 at 14:04 -0400, Jeff Spaleta wrote: > On 7/13/05, seth vidal wrote: > > I need to add a 'pull comps.xml from cvs' to the extras-push script so > > it gets updated with any regularity. > > Would there be a need for branch specific comps.xml files since > fc3,fc4 and devel have different package collections available in > extras? i think different ones per release makes sense. > Or is it fine to have one comps.xml file that includes > references to packages that aren't in a tree? you can but it looks sloppy > Would a missing > mandatory group member screw up groupinstall commands? it won't. missing group members are not fatal errors for yum. > Also would it make since for there to be an equivalent to the tag and > build request action packages have for the comps.xml, so that your > scripted pull gets only a version tagged for consumption instead of > some interim version thats being worked on? I don't see any reason why we would apply different rules to the comps.xml file than to the packages themselves. -sv From katzj at redhat.com Wed Jul 13 18:08:07 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Jul 2005 14:08:07 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507131104553ee8ef@mail.gmail.com> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <1121274222.11215.3.camel@cutter> <604aa7910507131104553ee8ef@mail.gmail.com> Message-ID: <1121278088.3578.12.camel@bree.local.net> On Wed, 2005-07-13 at 14:04 -0400, Jeff Spaleta wrote: > On 7/13/05, seth vidal wrote: > > I need to add a 'pull comps.xml from cvs' to the extras-push script so > > it gets updated with any regularity. > > Would there be a need for branch specific comps.xml files since > fc3,fc4 and devel have different package collections available in > extras? Or is it fine to have one comps.xml file that includes > references to packages that aren't in a tree? Would a missing > mandatory group member screw up groupinstall commands? Missing packages shouldn't cause problems. At the same time, I'd recommend comps-fe3.xml, comps-fe4.xml, etc. That mirrors what we do with Core (and allows you to change the groups over time) > Also would it make since for there to be an equivalent to the tag and > build request action packages have for the comps.xml, so that your > scripted pull gets only a version tagged for consumption instead of > some interim version thats being worked on? Tagging isn't a bad idea, probably more like the tagging for the website than for packages, though. Jeremy From ivazquez at ivazquez.net Wed Jul 13 18:34:24 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Jul 2005 14:34:24 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <20050713115228.GI8191@redhat.com> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> <20050713115228.GI8191@redhat.com> Message-ID: <1121279664.31100.1.camel@ignacio.lan> On Wed, 2005-07-13 at 07:52 -0400, Daniel Veillard wrote: > On Tue, Jul 12, 2005 at 06:39:21PM -0400, Ignacio Vazquez-Abrams wrote: > > On Tue, 2005-07-12 at 05:53 -0400, Daniel Veillard wrote: > > > If that renaming is done I would be okay to sponsor that package if needed. > > > > Updated, with a note in %description. > > I started to look up more closely to teh spec file, there is a number > of annoying things, sorry I didn't looked more closely in the first pass: > > BuildRequires: misses libxml2-devel > I think > Requires should at least list libxml2 > Why link against the static versions of the libraries ? > make EXTRA_LIBS="/usr/lib/libgcrypt.a /usr/lib/libgpg-error.a" > Can't this check be done the normal way from configure ? > > paphio:~ -> ldd /usr/bin/xmlstarlet > libz.so.1 => /usr/lib/libz.so.1 (0x00ae8000) > libm.so.6 => /lib/tls/libm.so.6 (0x00ef6000) > libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00ce4000) > libdl.so.2 => /lib/libdl.so.2 (0x00deb000) > libc.so.6 => /lib/tls/libc.so.6 (0x00111000) > /lib/ld-linux.so.2 (0x00c3a000) > > There is a big problem here: libxml2 is not referenced dynamically, it > should. I didn't looked at the MAkefile.am or configure but there > is something wrong: it should use xml2-config --cflags and > xml2-config --libs to interface with libxml2. As a result it also > link in -lpthread while this is actaully not needed anymore. > > I think this is a bit too much to allow this in the current state to get > in. It would be cool if you can get those fixed, Fair enough. In that case I withdraw this package until further notice. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jspaleta at gmail.com Wed Jul 13 20:18:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 13 Jul 2005 16:18:36 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121278088.3578.12.camel@bree.local.net> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <1121274222.11215.3.camel@cutter> <604aa7910507131104553ee8ef@mail.gmail.com> <1121278088.3578.12.camel@bree.local.net> Message-ID: <604aa7910507131318adea018@mail.gmail.com> On 7/13/05, Jeremy Katz wrote: > Tagging isn't a bad idea, probably more like the tagging for the website > than for packages, though. whatever works to prevent a work in progress comps file from showing up in a consumable tree. -jef From jspaleta at gmail.com Wed Jul 13 20:44:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 13 Jul 2005 16:44:39 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> Message-ID: <604aa7910507131344688f9dd1@mail.gmail.com> On 7/13/05, Greg DeKoenigsberg wrote: > 1. Eric, get CVS access. It's documented under "how to be a contributor." > 2. Create the repo for comps in /cvs/fedora. Sopwith? Jeremy? > 3. Eric, start hacking. > > Is that pretty much it? I think there needs to be some helpful guidelines as to what group definitions are going to be blessable and what packages should be considered manadatory,default or optional inside a group. Requests for addiing a package to a pre-existing gorup definition as an optional package is just a matter of hacking the file... every package maintainer could do this as easily as Eric or I could until there is some sort of automatation available via cvs make logic. There is very little room for rational argument when adding a package to a pre-existing group as an optional member. Optional members are pulled in by default installs via s-c-p or anaconda or yum groupinstall afaik... so the possible negative impact to accepting all requests for packages as optional members of a group is minimal. The more problematic issues are what to do is there is a request to add a new visible group or there is a request to add a package as a manadatory or default member of a group. There needs to be some overall understanding in the contributor pool as to when requesting a new group is appropriate... when requesting a package or package group be made a mandatory or default member of a group. And I certaintly don't feel comfortable adding group definitions or adding packages as mandatory group members willy-nilly. -jef From gdk at redhat.com Wed Jul 13 20:50:21 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 13 Jul 2005 16:50:21 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507131344688f9dd1@mail.gmail.com> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <604aa7910507131344688f9dd1@mail.gmail.com> Message-ID: So if Eric accepts the responsibility for doing this work, I think it's fair that he also accept the work of fleshing out policy. Or at least leading that effort. Gee, we're volunteering him for a lot. ;-) --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Wed, 13 Jul 2005, Jeff Spaleta wrote: > On 7/13/05, Greg DeKoenigsberg wrote: > > 1. Eric, get CVS access. It's documented under "how to be a contributor." > > 2. Create the repo for comps in /cvs/fedora. Sopwith? Jeremy? > > 3. Eric, start hacking. > > > > Is that pretty much it? > > I think there needs to be some helpful guidelines as to what group > definitions are going to be blessable and what packages should be > considered manadatory,default or optional inside a group. > > Requests for addiing a package to a pre-existing gorup definition as > an optional package is just a matter of hacking the file... every > package maintainer could do this as easily as Eric or I could until > there is some sort of automatation available via cvs make logic. > There is very little room for rational argument when adding a package > to a pre-existing group as an optional member. Optional members are > pulled in by default installs via s-c-p or anaconda or yum > groupinstall afaik... so the possible negative impact to accepting all > requests for packages as optional members of a group is minimal. > > The more problematic issues are what to do is there is a request to > add a new visible group or there is a request to add a package as a > manadatory or default member of a group. There needs to be some > overall understanding in the contributor pool as to when requesting a > new group is appropriate... when requesting a package or package group > be made a mandatory or default member of a group. And I certaintly > don't feel comfortable adding group definitions or adding packages as > mandatory group members willy-nilly. > > -jef > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From notting at redhat.com Wed Jul 13 21:05:52 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Jul 2005 17:05:52 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507131344688f9dd1@mail.gmail.com> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <604aa7910507131344688f9dd1@mail.gmail.com> Message-ID: <20050713210552.GA30082@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > I think there needs to be some helpful guidelines as to what group > definitions are going to be blessable and what packages should be > considered manadatory,default or optional inside a group. > > Requests for addiing a package to a pre-existing gorup definition as > an optional package is just a matter of hacking the file... every > package maintainer could do this as easily as Eric or I could until > there is some sort of automatation available via cvs make logic. > There is very little room for rational argument when adding a package > to a pre-existing group as an optional member. Optional members are > pulled in by default installs via s-c-p or anaconda or yum > groupinstall afaik... so the possible negative impact to accepting all > requests for packages as optional members of a group is minimal. Generally, all additions to existing groups are optional, and mandatory is only reserved for groups that are separate to Extras (for example, mandatory could be used for packages in the XFCE group.) Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 13 21:15:19 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jul 2005 23:15:19 +0200 Subject: Request for review : gkrellm-bmp Message-ID: <20050713231519.7d4d0870@python2> Hi, I've packaged gkrellm-bmp and gkrellm-xmms, just to notice that gkrellmms was already in Extras (I had done a "yum search gkrellm-*"), and that's the plugin I used for both's original name. This means that although I'd personally prefer to see "gkrellm-xmms" as a package, obsoleting "gkrellmms", I'll only be submitting gkrellm-bmp for now. Here it is, ready for review : http://ftp.es6.freshrpms.net/tmp/extras/gkrellm-bmp/ Works great for me :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.16 0.17 0.06 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 13 21:26:35 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jul 2005 23:26:35 +0200 Subject: Request for review: gdome2 In-Reply-To: <1121197266.3420.3.camel@localhost.localdomain> References: <1121197266.3420.3.camel@localhost.localdomain> Message-ID: <20050713232635.15326bfa@python2> Ville Skytt? wrote : > libxml2 2.6.20 fixes XPath issues that affected gdome2, so now that an > errata is out, here's a request for review for it. For me, this is the > root of a smallish chain of missing dependencies towards getting XSH > (http://xsh.sf.net/) to Extras: > > gdome2 is a fast, light and complete DOM level 2 implementation based > on libxml2. Although it has been written for the GNOME project, it can > be used stand-alone. http://gdome2.cs.unibo.it/ > > http://cachalot.mine.nu/4/SRPMS/gdome2-0.8.1-0.2.src.rpm Looks good. Nice and clean spec as usual, a real pleasure to review! Bumping the release to 1 before importing would be a good things, though (you've probably already planned on doing that ;-)). I haven't tested the resulting build, but I assume you have for xsh, so consider it APPROVED. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.24 0.40 0.34 From lmacken at redhat.com Wed Jul 13 21:24:11 2005 From: lmacken at redhat.com (Luke Macken) Date: Wed, 13 Jul 2005 17:24:11 -0400 Subject: Request for Review: nethack In-Reply-To: <1121047290.22400.79.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050711003357.GA4401@enlartenment.com> <20050711005745.GA5213@tomservo.boston.redhat.com> <1121047290.22400.79.camel@localhost.localdomain> Message-ID: <20050713212411.GA12491@tomservo.boston.redhat.com> On Sun, Jul 10, 2005 at 09:01:30PM -0500, Tom 'spot' Callaway wrote: | "recover" is a very very generic name. If this ends up in the default | $PATH, please rename it to "nethack-recover". With that caveat, I see no | reason these files can't live in %{_bindir} (I was always annoyed that | the default location wasn't in my path). Ok, I 'recover' is now %{_bindir}/nethack-recover. The 'nethack' binary in the gamedir is actually run by a shell the shell script %{_bindir}/nethack (this script just looks for a PAGER and does other useless stuff and can most likely be removed). So at the moment things are still in /usr/games/nethack. | > | RPMlint says the following: | > | | > | W: nethack unstripped-binary-or-object /usr/games/nethack/nethack | | This usually means that the file is not chmod +x. Try doing that in | %install, it should make the error go away. That doesn't seem to be working. | > | E: nethack zero-length /var/games/nethack/logfile | > | E: nethack zero-length /var/games/nethack/record | > | E: nethack zero-length /var/games/nethack/perm | | All of these will likely go away if you make them %ghost. Can't %ghost them, because they need to exist for nethack to run (unless we `touch` them in %post or something?) | > | E: nethack non-standard-dir-perm /var/games/nethack 0775 | > | E: nethack non-standard-executable-perm /usr/games/nethack/nethack 02755 | > | E: nethack non-standard-dir-perm /var/games/nethack/save 0775 | | Nethack shouldn't need to be using these odd permissions. Try just 775 | and 755. I can't seem to make the game happy with any permissions other than these. luke From alex at dalloz.de Wed Jul 13 21:55:53 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 13 Jul 2005 23:55:53 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121100153.22665.295.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> Message-ID: <1121291752.1574.393.camel@serendipity.dogma.lan> Am Mo, den 11.07.2005 schrieb Alexander Dalloz um 18:42: > Hello fellows! > Alexander Its me again - next round for a review :) http://www.uni-x.org/pam_abl-0.2.2-1.src.rpm http://www.uni-x.org/pam_abl.spec Beside changes to be found in %changelog some additional notes: - the author of pam_abl Andy Armstrong replied very quickly and friendly to my mail: future versions will no longer have the date string in the tarball's name; releases are only differed by the release number (current on is 0.2.2) so I changed the release tag, being aware that this would mean a lower value now than before; think it does no harm here as the package is still in review and the former one histore now - running rpmlint gives me: $ rpmlint pam_abl-0.2.2-1.i386.rpm E: pam_abl library-not-linked-against-libc /lib/security/pam_abl.so I am confused as of: $ ldd /lib/security/pam_abl.so libdb-4.2.so => /lib/tls/libdb-4.2.so (0x00a9e000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x003d7000) libc.so.6 => /lib/tls/libc.so.6 (0x00111000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x008fd000) - Oliver, rereading your first review I noticed that you commented about the .spec file: * You should not make Could you please tell me what is meant by that? Further critics appreciated, but would be glad too to hear this is a major step forward to being approved. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Wed Jul 13 22:01:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 13 Jul 2005 18:01:01 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050713210552.GA30082@nostromo.devel.redhat.com> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <604aa7910507131344688f9dd1@mail.gmail.com> <20050713210552.GA30082@nostromo.devel.redhat.com> Message-ID: <604aa791050713150157df4552@mail.gmail.com> On 7/13/05, Bill Nottingham wrote: > Generally, all additions to existing groups are optional, and mandatory > is only reserved for groups that are separate to Extras (for example, > mandatory could be used for packages in the XFCE group.) I'm more than happy to help out editting comps to include optional members of a group and personally ignoring all requests for any other designation. But I'm not sure what to do about any requests to add a new group. The groupname space is wholely without rhyme nor reason. Even Core groups do not fit in a simple paradigm which can be used as a guide. And I weary of creating a group that put a "small" set of similar but unrelated packages together just because it can be done. An explosion of lots and lots of tiny groups is probably worth avoiding... unless you share my dream to see xsnow, xwaves and oneko together under the group heading "Pointless X root window toys". -jef From veillard at redhat.com Wed Jul 13 22:17:05 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 13 Jul 2005 18:17:05 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <1121279664.31100.1.camel@ignacio.lan> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> <20050713115228.GI8191@redhat.com> <1121279664.31100.1.camel@ignacio.lan> Message-ID: <20050713221705.GB8191@redhat.com> [cc'ing the author of xmlstarlet] On Wed, Jul 13, 2005 at 02:34:24PM -0400, Ignacio Vazquez-Abrams wrote: > > I think this is a bit too much to allow this in the current state to get > > in. It would be cool if you can get those fixed, > > Fair enough. In that case I withdraw this package until further notice. Note that Ville Skytt? is pushing gdome2 to target xsh. In my opionion xsh and xmlstartlet are competing, both are wrappers around libxml2 to provide XML oriented scripting. I honnestly don't know which one might be better or more complete. xmlstarlet seems to be somewhat actively developped last release was 2005-03-15 and there was another one in January. However in Sep 2004 Mikhail S Grushinskiy the author wanted to donate the code of xmlstar to the libxml2/libxslt projects. http://mail.gnome.org/archives/xml/2004-September/msg00158.html Mikhail we are looking at integrating xmlstarlet in Fedora Core Extra but we have a couple of technical difficulties, https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00637.html your opinion would be welcome :-) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From katzj at redhat.com Wed Jul 13 22:26:01 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Jul 2005 18:26:01 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa791050713150157df4552@mail.gmail.com> References: <200507131007.47065.ermeyers@adelphia.net> <1121269762.15220.132.camel@ernie> <1121270101.3578.3.camel@bree.local.net> <604aa7910507131344688f9dd1@mail.gmail.com> <20050713210552.GA30082@nostromo.devel.redhat.com> <604aa791050713150157df4552@mail.gmail.com> Message-ID: <1121293561.6007.10.camel@bree.local.net> On Wed, 2005-07-13 at 18:01 -0400, Jeff Spaleta wrote: > On 7/13/05, Bill Nottingham wrote: > > Generally, all additions to existing groups are optional, and mandatory > > is only reserved for groups that are separate to Extras (for example, > > mandatory could be used for packages in the XFCE group.) > > I'm more than happy to help out editting comps to include optional > members of a group and personally ignoring all requests for any other > designation. > > But I'm not sure what to do about any requests to add a new group. The > groupname space is wholely without rhyme nor reason. Even Core groups > do not fit in a simple paradigm which can be used as a guide. Okay, I'm willing to carve out some portion of time for that sort of arbitration. Especially as I already do so to some extent for Core. So requests for new groups, hit me! :) Jeremy From fedora at tqmcube.com Wed Jul 13 22:30:04 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Wed, 13 Jul 2005 18:30:04 -0400 Subject: Request for Review: leafnode-1.11.3-2.FC4.src.rpm Message-ID: <1121293804.2127.104.camel@dch.TQMcube.com> Muddling my way through all of this, since this was an update to an existing package, I committed the new sources and spec to CVS. A source RPM is at ftp://ftp.tqmcube.com/leafnode-1.11.3-2.FC4.src.rpm . -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From tibbs at math.uh.edu Wed Jul 13 22:42:10 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 13 Jul 2005 17:42:10 -0500 Subject: Request for Review: nethack In-Reply-To: <1121047290.22400.79.camel@localhost.localdomain> (Tom Callaway's message of "Sun, 10 Jul 2005 21:01:30 -0500") References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050711003357.GA4401@enlartenment.com> <20050711005745.GA5213@tomservo.boston.redhat.com> <1121047290.22400.79.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom Callaway writes: TC> Nethack shouldn't need to be using these odd permissions. Try just TC> 775 and 755. Nethack generally needs to be setgid games in order to write to the high scores and bones files (and perhaps to keep users from backing up their characters). - J< From bdpepple at ameritech.net Wed Jul 13 22:43:02 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 13 Jul 2005 18:43:02 -0400 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050713231519.7d4d0870@python2> References: <20050713231519.7d4d0870@python2> Message-ID: <1121294582.3432.1.camel@shuttle.273piedmont.com> On Wed, 2005-07-13 at 23:15 +0200, Matthias Saou wrote: > I've packaged gkrellm-bmp and gkrellm-xmms, just to notice that gkrellmms > was already in Extras (I had done a "yum search gkrellm-*"), and that's > the plugin I used for both's original name. > > This means that although I'd personally prefer to see "gkrellm-xmms" as a > package, obsoleting "gkrellmms", I'll only be submitting gkrellm-bmp for > now. > > Here it is, ready for review : > http://ftp.es6.freshrpms.net/tmp/extras/gkrellm-bmp/ > I currently maintain the package for gkrellmms, but if you have an interest in taking it over, I'd have no problem. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 ivazquez at ivazquez.net Wed Jul 13 22:46:43 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Jul 2005 18:46:43 -0400 Subject: Request for Review: leafnode-1.11.3-2.FC4.src.rpm In-Reply-To: <1121293804.2127.104.camel@dch.TQMcube.com> References: <1121293804.2127.104.camel@dch.TQMcube.com> Message-ID: <1121294803.31100.4.camel@ignacio.lan> On Wed, 2005-07-13 at 18:30 -0400, David Cary Hart wrote: > Muddling my way through all of this, since this was an update to an > existing package, I committed the new sources and spec to CVS. Updates to existing packages don't require a separate review. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 fedora at tqmcube.com Wed Jul 13 22:49:43 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Wed, 13 Jul 2005 18:49:43 -0400 Subject: Request for Review: leafnode-1.11.3-2.FC4.src.rpm In-Reply-To: <1121294803.31100.4.camel@ignacio.lan> References: <1121293804.2127.104.camel@dch.TQMcube.com> <1121294803.31100.4.camel@ignacio.lan> Message-ID: <1121294983.2127.116.camel@dch.TQMcube.com> On Wed, 2005-07-13 at 18:46 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-07-13 at 18:30 -0400, David Cary Hart wrote: > > Muddling my way through all of this, since this was an update to an > > existing package, I committed the new sources and spec to CVS. > > Updates to existing packages don't require a separate review. > Yes. I just thought some might want to take a look before I requested a build but OK. First package - still uncertain. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From fedora at tqmcube.com Wed Jul 13 22:51:49 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Wed, 13 Jul 2005 18:51:49 -0400 Subject: Request for Build: leafnode-1.11.3-2.fc4 Message-ID: <1121295109.2127.119.camel@dch.TQMcube.com> -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From bugs.michael at gmx.net Wed Jul 13 23:18:05 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Jul 2005 01:18:05 +0200 Subject: Request for Build: leafnode-1.11.3-2.fc4 In-Reply-To: <1121295109.2127.119.camel@dch.TQMcube.com> References: <1121295109.2127.119.camel@dch.TQMcube.com> Message-ID: <20050714011805.24b3708c.bugs.michael@gmx.net> On Wed, 13 Jul 2005 18:51:49 -0400, David Cary Hart wrote: > Build requests would be done with running "make build" in your CVS checkout. http://fedoraproject.org/wiki/Extras/BuildRequests http://fedoraproject.org/wiki/Extras/UsingCvsFaq But the build system is inoperative since last weekend, because it is being worked on installing and testing the new build system code. News about it are expected to be posted to maintainers' list, and most likely this list, too. From kaboom at oobleck.net Thu Jul 14 03:59:33 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 13 Jul 2005 23:59:33 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050711042857.GA7425@nostromo.devel.redhat.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: On Mon, 11 Jul 2005, Bill Nottingham wrote: > Yeah, that's the problematic thing here. For example, when the > currently existing comps.xml was made, some of the stuff was easy > (all Games grouped together, Development Tools, etc.) > > However, that only accounts for a subset of packages. Realistically, > random libraries shouldn't be listed, except perhaps for the -devel > pacakge in one of the development library groups. And some of the > packages defy simple categorization, unless you have a group for each > package. Which... no. For grins, I started with the FC 4 comps.xml, stripped out all the internationalized descriptions (just to make it readable / shorter -- they can be added back later), and made a comps for all the packages beginning with "a" from FE devel. See attached. General rules I followed: * didn't create any new groups * only listed libraries that seemed reasonably general Some observations: * categorization takes longer than you'd expect ;-) * there are some categories which seem overly broad; system-tools for example could be broken up more * some stuff didn't fit any existing categories (allegro-tools, for one) Thoughts? later, chris -------------- next part -------------- A non-text attachment was scrubbed... Name: comps-fe.devel.xml.gz Type: application/x-gzip Size: 3842 bytes Desc: URL: From kaboom at oobleck.net Thu Jul 14 04:06:45 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 00:06:45 -0400 (EDT) Subject: No more right click terminal In-Reply-To: <1121272795.13335.18.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <55143.192.54.193.37.1121249878.squirrel@rousalka.dyndns.org> <1121272795.13335.18.camel@localhost.localdomain> Message-ID: On Wed, 13 Jul 2005, Per Bjornsson wrote: > Perhaps the trick for Gnome is to market the various extension > possibilities more. Clearly fun stuff is possible (Nautilus extensions, > look at Brightside and Devilspie for WM crack...) In fact I think that > this to a great extent is actually a marketing problem rather than a > technical problem. But marketing is serious stuff, so a marketing > problem is certainly a real problem, not something to handwave away... That reminds me, I packaged Devil's Pie a while ago but hadn't asked for a review for inclusion in FE yet I know there's a newer release out for Gnome 2.10 -- I'll update the package to that in a day or two when I do more packaging stuff.... later, chris From notting at redhat.com Thu Jul 14 04:19:52 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 14 Jul 2005 00:19:52 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: <20050714041952.GB905@nostromo.devel.redhat.com> Chris Ricker (kaboom at oobleck.net) said: > On Mon, 11 Jul 2005, Bill Nottingham wrote: > > > Yeah, that's the problematic thing here. For example, when the > > currently existing comps.xml was made, some of the stuff was easy > > (all Games grouped together, Development Tools, etc.) > > > > However, that only accounts for a subset of packages. Realistically, > > random libraries shouldn't be listed, except perhaps for the -devel > > pacakge in one of the development library groups. And some of the > > packages defy simple categorization, unless you have a group for each > > package. Which... no. > > For grins, I started with the FC 4 comps.xml, stripped out all the > internationalized descriptions (just to make it readable / shorter -- they > can be added back later), and made a comps for all the packages beginning > with "a" from FE devel. See attached. > > General rules I followed: > > * didn't create any new groups > * only listed libraries that seemed reasonably general > > Some observations: > > * categorization takes longer than you'd expect ;-) > * there are some categories which seem overly broad; system-tools for > example could be broken up more > * some stuff didn't fit any existing categories (allegro-tools, for one) For reference, here's the simplified version of what I believe Extras is currently using. Bill -------------- next part -------------- admin-tools <_name>Administration Tools <_description>This group is a collection of graphical administration tools for the system, such as for managing user accounts and configuring system hardware. false true authoring-and-publishing <_name>Authoring and Publishing <_description>These tools allow you to create documentation in the DocBook format and convert them to HTML, PDF, Postscript, and text. false true conglomerate kile scribus base <_name>Base <_description>This group includes a minimal set of packages. Useful for creating small router/firewall boxes, for example. true false core <_name>Core <_description>Smallest possible installation true false dns-server <_name>DNS Name Server <_description>This package group allows you to run a DNS name server (BIND) on the system. false true development-libs <_name>Development Libraries <_description>The packages in this group are core libraries needed to develop applications. false false development-tools <_name>Development Tools <_description>These tools include core development tools such as automake, gcc, perl, python, and debuggers. false true anjuta anjuta-docs bazaar cdiff colordiff cpan2rpm cvsps cvsweb fedora-rpmdevtools gazpacho lincvs meld ocaml rpmdiff rpmproc tkcvs tla dialup <_name>Dialup Networking Support <_description> true false pptp editors <_name>Editors <_description>Sometimes called text editors, these are programs that allow you to create and edit files. These include Emacs and Vi. false true base xemacs jed leafpad TeXmacs engineering-and-scientific <_name>Engineering and Scientific <_description>This group includes packages for performing mathematical and scientific computations and plotting, as well as unit conversion. false true blacs blas galculator lapack R R-gnomeGUI scalapack ftp-server <_name>FTP Server <_description>These tools allow you to run an FTP server on the system. false true proftpd pure-ftpd gnome-desktop <_name>GNOME Desktop Environment <_description>GNOME is a powerful, graphical user interface which includes a panel, desktop, system icons, and a graphical file manager. true true themes-backgrounds-gnome gnome-software-development <_name>GNOME Software Development <_description>Install these packages in order to develop GTK+ and GNOME graphical applications. false true games <_name>Games and Entertainment <_description>Various ways to relax and spend your free time. false true abe bzflag celestia cgoban csmash enigma foobillard fortune-mod freeciv freedroid freedroidrpg gl-117 gnofract4d gnuchess gnugo lmarbles Maelstrom neverball powermanga ppracer qascade qqo scorched3d sirius sopwith starfighter stellarium supertux torcs tuxtype2 uqm viruskiller wesnoth xboard xplanet graphical-internet <_name>Graphical Internet <_description>This group includes graphical email, Web, and chat clients. true true amaya balsa bittorrent-gui bluefish contact-lookup-applet deskbar-applet dillo gnome-blog gnome-telnet gwget kickpim kphone liferea linphone logjam prozilla putty screem silky straw sylpheed sylpheed-claws x3270 graphics <_name>Graphics <_description>This group includes packages to help you manipulate and scan images. true true blender gqview graphviz gwenview inkscape showimg skencil sodipodi tuxpaint kde-desktop <_name>KDE (K Desktop Environment) <_description>KDE is a powerful, graphical user interface which includes a panel, desktop, system icons, and a graphical file manager. false true kde-software-development <_name>KDE Software Development <_description>Install these packages to develop QT and KDE graphical applications. false true legacy-network-server <_name>Legacy Network Server <_description>These packages include servers for old network protocols such as rsh and telnet. false true mail-server <_name>Mail Server <_description>These packages allow you to configure an IMAP or Postfix mail server. false true cyrus-imapd cyrus-imapd-murder cyrus-imapd-nntp cyrus-imapd-utils perl-Cyrus clamav clamav-data clamav-milter exim exom-doc pyzor mysql <_name>MySQL Database <_description>This package group contains packages useful for use with MySQL. false true network-server <_name>Network Servers <_description>These packages include network-based servers such as DHCP, Kerberos and NIS. false true news-server <_name>News Server <_description>This group allows you to configure the system as a news server. false true leafenode suck office <_name>Office/Productivity <_description>The applications include office suites, PDF viewers, and more. true true abiword gdeskcal gnotime gnumeric gossip grisbi gsview notecase notemeister qcad xfcalendar sql-server <_name>PostgreSQL Database <_description>This package group includes packages useful for use with Postgresql. false true printing <_name>Printing Support <_description>Install these tools to enable the system to print or act as a print server. true true ruby <_name>Ruby <_description>Basic support for the Ruby programming language. false false server-cfg <_name>Server Configuration Tools <_description>This group contains all of Red Hat's custom server configuration tools. false true sound-and-video <_name>Sound and Video <_description>From CD recording to playing audio CDs and multimedia files, this package group allows you to work with sound and video on the system. true true abcde amarok amarok-visualisation audacity bmp camE flumotion gcombust graveman grip kover soundtracker xmms xmms-cdread xmms-flac system-tools <_name>System Tools <_description>This group is a collection of various tools for the system, such as the client for connecting to SMB shares and tools to monitor network traffic. false true apt cfengine epylog fwbuilder ghex moodss rdiff-backup sabayon shorewall shorewall-doc synaptic vnstat vpnc text-internet <_name>Text-based Internet <_description>This group includes text-based email, Web, and chat clients. These applications do not require the X Window System. true true bittorrent centericq cone cone-doc elmo irssi ncftp nget ninja nmh snownews tin web-server <_name>Web Server <_description>These tools allow you to run a Web server on the system. false true apachetop awstats boa lighttpd lighttpd-fastcgi plone thttpd zope smb-server <_name>Windows File Server <_description>This package group allows you to share files between Linux and MS Windows(tm) systems. false true x-software-development <_name>X Software Development <_description>These packages allow you to develop applications for the X Window System. false true base-x <_name>X Window System <_description>Install this group of packages to use the base graphical (X) user interface. true true xemacs <_name>XEmacs <_description>The XEmacs text editor. false false base xemacs xemacs-el xemacs-info xemacs-sumo xemacs-sumo-el xemacs-sumo-info xfce-desktop <_name>XFCE <_description>A lightweight desktop environment that works well on low end machines. false true libxfce4mcs libxfce4util libxfcegui4 xfce-mcs-manager xfce-mcs-plugins xfce-utils xfce4-iconbox xfce4-panel xfce4-systray xfdesktop xffm xffm-icons xfprint xfwm4 xfce4-toys xfwm4-themes xfwm4-themes xfce-software-development <_name>XFCE Software Development <_description>Install these packages in order to develop GTK+ and XFCE graphical applications. false true x-software-development glade2 glib2-devel gtk-doc gtk2-devel libxfce4mcs-devel libxfce4util-devel libxfcegui4-devel pygtk2-devel xfce-mcs-manager-devel <_name>Desktops base-x gnome-desktop kde-desktop xfce-desktop <_name>Development development-tools kernel-development x-software-development gnome-software-development kde-software-development xfce-software-development compat-arch-development legacy-software-development x86-compat-arch-development java-development eclipse From skvidal at phy.duke.edu Thu Jul 14 06:14:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 02:14:34 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: <1121321674.13861.0.camel@cutter> On Wed, 2005-07-13 at 23:59 -0400, Chris Ricker wrote: > On Mon, 11 Jul 2005, Bill Nottingham wrote: > > > Yeah, that's the problematic thing here. For example, when the > > currently existing comps.xml was made, some of the stuff was easy > > (all Games grouped together, Development Tools, etc.) > > > > However, that only accounts for a subset of packages. Realistically, > > random libraries shouldn't be listed, except perhaps for the -devel > > pacakge in one of the development library groups. And some of the > > packages defy simple categorization, unless you have a group for each > > package. Which... no. > > For grins, I started with the FC 4 comps.xml, stripped out all the > internationalized descriptions (just to make it readable / shorter -- they > can be added back later), and made a comps for all the packages beginning > with "a" from FE devel. See attached. > > General rules I followed: > > * didn't create any new groups > * only listed libraries that seemed reasonably general > > Some observations: > > * categorization takes longer than you'd expect ;-) > * there are some categories which seem overly broad; system-tools for > example could be broken up more > * some stuff didn't fit any existing categories (allegro-tools, for one) > Here's the way I've always thought it would work well to break up extras into groups. download all of extras into a dir then start making subdirs of divisions you think make sense and move files into those dirs then index over those dirs and assemble the file that way. -sv From ville.skytta at iki.fi Thu Jul 14 06:13:41 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 09:13:41 +0300 Subject: Request for Review: xmlstartlet In-Reply-To: <20050713221705.GB8191@redhat.com> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> <20050713115228.GI8191@redhat.com> <1121279664.31100.1.camel@ignacio.lan> <20050713221705.GB8191@redhat.com> Message-ID: <1121321621.2872.48.camel@localhost.localdomain> On Wed, 2005-07-13 at 18:17 -0400, Daniel Veillard wrote: > [cc'ing the author of xmlstarlet] > > On Wed, Jul 13, 2005 at 02:34:24PM -0400, Ignacio Vazquez-Abrams wrote: > > > I think this is a bit too much to allow this in the current state to get > > > in. It would be cool if you can get those fixed, > > > > Fair enough. In that case I withdraw this package until further notice. > > Note that Ville Skytt? is pushing gdome2 to target xsh. In my opionion > xsh and xmlstartlet are competing, both are wrappers around libxml2 to > provide XML oriented scripting. I honnestly don't know which one might > be better or more complete. Ah, I wasn't aware of xmlstartlet, need to take a look at it sometime. If it makes it into Extras or libxml2/libxslt sooner than xsh, and provides the same or "better" functionality, I could imagine dropping pushing xsh. But I'm sure gdome2 will come in handy for other apps besides xsh. From ivazquez at ivazquez.net Thu Jul 14 06:31:10 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Jul 2005 02:31:10 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <1121321621.2872.48.camel@localhost.localdomain> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> <20050713115228.GI8191@redhat.com> <1121279664.31100.1.camel@ignacio.lan> <20050713221705.GB8191@redhat.com> <1121321621.2872.48.camel@localhost.localdomain> Message-ID: <1121322670.6290.5.camel@ignacio.lan> On Thu, 2005-07-14 at 09:13 +0300, Ville Skytt? wrote: > On Wed, 2005-07-13 at 18:17 -0400, Daniel Veillard wrote: > > Note that Ville Skytt? is pushing gdome2 to target xsh. In my opionion > > xsh and xmlstartlet are competing, both are wrappers around libxml2 to > > provide XML oriented scripting. I honnestly don't know which one might > > be better or more complete. > > Ah, I wasn't aware of xmlstartlet, need to take a look at it sometime. > If it makes it into Extras or libxml2/libxslt sooner than xsh, and > provides the same or "better" functionality, I could imagine dropping > pushing xsh. I took a quick look at xsh and it does seem to have a handy interactive mode. I'm sure there's room for both xsh and xmlstarlet in Extras. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ville.skytta at iki.fi Thu Jul 14 06:35:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 09:35:00 +0300 Subject: Request for review: gdome2 In-Reply-To: <20050713232635.15326bfa@python2> References: <1121197266.3420.3.camel@localhost.localdomain> <20050713232635.15326bfa@python2> Message-ID: <1121322900.2872.56.camel@localhost.localdomain> On Wed, 2005-07-13 at 23:26 +0200, Matthias Saou wrote: > Ville Skytt? wrote : > > > http://cachalot.mine.nu/4/SRPMS/gdome2-0.8.1-0.2.src.rpm > > Looks good. Nice and clean spec as usual, a real pleasure to review! Thanks. > Bumping the release to 1 before importing would be a good things, though > (you've probably already planned on doing that ;-)). Yes. Or actually I plan to bump it to 1%{?dist} after importing. > I haven't tested the resulting build, but I assume you have for xsh, so > consider it APPROVED. Great, importing while I write. From skvidal at phy.duke.edu Thu Jul 14 06:59:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 02:59:15 -0400 Subject: buildsys status report Message-ID: <1121324355.13861.18.camel@cutter> Hi All, Dan is the man and he has made it possible for things to work - and on smp processors even! :) Long and short successful package builds have occurred. It's like heaven on a sunday. It's sugar and spice. It's all things nice. Heck, I'll even throw in snails and puppy dog tails if that's your kink. Anyway - to do some more testing I'm going to push all the stuff in tobuild through the system and see what comes out the other side. The next steps: 1. get a list of all the extras committers/maintainers from Elliot and push them into the plague authN db. 2. write up the brief 'how do I use this' docs - this includes some info about certs and other items you'll need. 3. see if Dan is game for putting a version of plague IN extras so you, the developer, can install plague-client. 4. modify make build so it ends up calling plague-client 5. work on getting a webpage status report dump from the buildsys. 6. add new doodads and fix broken doodads. Sound like a passel of fun? I certainly hope so. -sv From ivazquez at ivazquez.net Thu Jul 14 07:07:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Jul 2005 03:07:09 -0400 Subject: buildsys status report In-Reply-To: <1121324355.13861.18.camel@cutter> References: <1121324355.13861.18.camel@cutter> Message-ID: <1121324829.6290.9.camel@ignacio.lan> On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > Hi All, > Dan is the man and he has made it possible for things to work - and on > smp processors even! :) Long and short successful package builds have > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > things nice. Heck, I'll even throw in snails and puppy dog tails if > that's your kink. What, no snips? Ah well, a job well done by both of you regardless ;) -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 skvidal at phy.duke.edu Thu Jul 14 07:09:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 03:09:06 -0400 Subject: buildsys status report In-Reply-To: <1121324829.6290.9.camel@ignacio.lan> References: <1121324355.13861.18.camel@cutter> <1121324829.6290.9.camel@ignacio.lan> Message-ID: <1121324946.13861.19.camel@cutter> On Thu, 2005-07-14 at 03:07 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > > Hi All, > > Dan is the man and he has made it possible for things to work - and on > > smp processors even! :) Long and short successful package builds have > > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > > things nice. Heck, I'll even throw in snails and puppy dog tails if > > that's your kink. > > What, no snips? Ah well, a job well done by both of you regardless ;) Give Dan the credit. I just break stuff. -sv From oliver at linux-kernel.at Thu Jul 14 07:08:33 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 09:08:33 +0200 Subject: buildsys status report In-Reply-To: <1121324355.13861.18.camel@cutter> References: <1121324355.13861.18.camel@cutter> Message-ID: <42D60F71.7020101@linux-kernel.at> On 07/14/2005 08:59 AM, seth vidal wrote: > Hi All, > Dan is the man and he has made it possible for things to work - and on > smp processors even! :) Long and short successful package builds have > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > things nice. Heck, I'll even throw in snails and puppy dog tails if > that's your kink. > > Anyway - to do some more testing I'm going to push all the stuff in > tobuild through the system and see what comes out the other side. > > The next steps: > 1. get a list of all the extras committers/maintainers from Elliot and > push them into the plague authN db. > 2. write up the brief 'how do I use this' docs - this includes some > info about certs and other items you'll need. > 3. see if Dan is game for putting a version of plague IN extras so you, > the developer, can install plague-client. > 4. modify make build so it ends up calling plague-client > 5. work on getting a webpage status report dump from the buildsys. > 6. add new doodads and fix broken doodads. > > Sound like a passel of fun? > > I certainly hope so. Sounds good! Dan, thanks a lot for working hard on this! Thanks Seth for keeping us up2date. Best, Oliver From oliver at linux-kernel.at Thu Jul 14 07:12:28 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 09:12:28 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <200507132353.05654.symbiont@berlios.de> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D5261F.9070401@linux-kernel.at> <20050713173051.1f10abef.bugs.michael@gmx.net> <200507132353.05654.symbiont@berlios.de> Message-ID: <42D6105C.4000204@linux-kernel.at> On 07/13/2005 05:53 PM, Jeff Pitman wrote: > On Wednesday 13 July 2005 23:30, Michael Schwendt wrote: > >>You are free to ignore such recommendations. I, for instance, would >>not like to be forced to add %{?dist} for a noarch/data package, >>which doesn't need a rebuild for the next distribution. > > > What about /usr/lib/python2.4/site-packages/foo in FC5 and > then /usr/lib/python2.5/site-packages/foo in FC6? > > Lots of noarchs need rebuild for next distro. Especially those that > involve ver-dependent directory structures. I also think, that the dist tag should always be added. Yes, there are some packages, where you only install a script in a path that doesn't change (eg. /etc), but to be sure, it's better to write the tag... Especially, as Jeff mentions here, perl or python modules. Best, Oliver From oliver at linux-kernel.at Thu Jul 14 07:21:12 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 09:21:12 +0200 Subject: Request for review: bwm-ng In-Reply-To: <20050713180009.25cfeb09@python2> References: <42CE7809.3090202@linux-kernel.at> <42D280D6.6040201@linux-kernel.at> <42D50DF5.7020709@linux-kernel.at> <20050713180009.25cfeb09@python2> Message-ID: <42D61268.8070009@linux-kernel.at> On 07/13/2005 06:00 PM, Matthias Saou wrote: > Oliver Falk wrote : > > >>>>Please review/approve. >>> >>>Noone saw this, did you? >> >>Still now answer? :-/ > > > Here's one :-) > I'm a little lazy to list all the changes I've made... see the patch. > > Main remarks : > - Source URL wasn't valid anymore Thanks. > - Summary started with "A ..." OK. > - You seem to not be friends with tabulations ;-) ^^^ I AM! :-) > - Stripping must be avoided to get useful debuginfo packages Oops. > - You forgot to include the man page OK. > - Passing defaults to configure only decreases readability (IMHO) Correct. Merci. > And last, the big blocks of comments which are completely redundant with > the spec file delimiter right below (i.e. %description, %prep, %build, > %install...) should be avoided since they're not really useful as long as > you have proper syntax colouring, and can trigger unwanted side-effects, > most notably their inclusion into %pre*/%post* scriplets (although there > are none in this particular packages). This was a specfile template from my old company... :-) :-/ > Please merge in the changes that you like, then I'll review again. Applied, please review/approve: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/bwm-ng Best, Oliver From oliver at linux-kernel.at Thu Jul 14 07:36:07 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 09:36:07 +0200 Subject: [Fwd: Request for review: libdnet] In-Reply-To: <42D544E6.4010503@di.uminho.pt> References: <42CE7705.2090002@linux-kernel.at> <42D544E6.4010503@di.uminho.pt> Message-ID: <42D615E7.8080705@linux-kernel.at> On 07/13/2005 06:44 PM, Jos? Pedro Oliveira wrote: > Oliver, > > >>SRPM & SPEC: >>http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet > > > Todo list: > * use "%setup -q" instead of %setup (-q -> quiet mode) > * use "make install DESTDIR=..." instead of %makeinstall > * wrong group in the progs subpackage > * %post/%postun scripts missing > * library (.so ) in the wrong package > * don't include the .la file > * missing doc files (LICENSE is critical) > * don't overuse the %attr macros. There is nothing wrong > with the default file permissions > * don't use TABs in specfiles > * and run rpmlint before submitting a package for review > > jpo Thanks, Jos?. Please review again/approve, new release (2) has just been uploaded: http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet/ Best, Oliver From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 14 07:37:58 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Jul 2005 09:37:58 +0200 Subject: Request for review: bwm-ng In-Reply-To: <42D61268.8070009@linux-kernel.at> References: <42CE7809.3090202@linux-kernel.at> <42D280D6.6040201@linux-kernel.at> <42D50DF5.7020709@linux-kernel.at> <20050713180009.25cfeb09@python2> <42D61268.8070009@linux-kernel.at> Message-ID: <20050714093758.3943a1ac@python2> Oliver Falk wrote : > > - You seem to not be friends with tabulations ;-) > ^^^ I AM! :-) Hmmm, nope : Some of the headers aren't aligned, the fist configure option either, and some end with a space while others end with a tab... that's what I meant, it lacks consistency and ends up not being aligned properly (at least for me :-/). > Applied, please review/approve: > http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/bwm-ng Apart from the cosmetic problems I've just mentioned, looks good, builds and runs fine, so I APPROVE the package ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.06 0.19 0.13 From oliver at linux-kernel.at Thu Jul 14 07:56:27 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 09:56:27 +0200 Subject: Request for review: bwm-ng In-Reply-To: <20050714093758.3943a1ac@python2> References: <42CE7809.3090202@linux-kernel.at> <42D280D6.6040201@linux-kernel.at> <42D50DF5.7020709@linux-kernel.at> <20050713180009.25cfeb09@python2> <42D61268.8070009@linux-kernel.at> <20050714093758.3943a1ac@python2> Message-ID: <42D61AAB.8000005@linux-kernel.at> On 07/14/2005 09:37 AM, Matthias Saou wrote: > Oliver Falk wrote : > > > >>>- You seem to not be friends with tabulations ;-) >> >> ^^^ I AM! :-) > > > Hmmm, nope : Some of the headers aren't aligned, the fist configure option > either, and some end with a space while others end with a tab... that's > what I meant, it lacks consistency and ends up not being aligned properly > (at least for me :-/). > > >>Applied, please review/approve: >>http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/bwm-ng > > > Apart from the cosmetic problems I've just mentioned, looks good, builds > and runs fine, so I APPROVE the package ;-) Merci! From paul at city-fan.org Thu Jul 14 08:06:51 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 14 Jul 2005 09:06:51 +0100 Subject: buildsys status report In-Reply-To: <1121324355.13861.18.camel@cutter> References: <1121324355.13861.18.camel@cutter> Message-ID: <1121328412.25207.98.camel@laurel.intra.city-fan.org> On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > Hi All, > Dan is the man and he has made it possible for things to work - and on > smp processors even! :) Long and short successful package builds have > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > things nice. Heck, I'll even throw in snails and puppy dog tails if > that's your kink. > > Anyway - to do some more testing I'm going to push all the stuff in > tobuild through the system and see what comes out the other side. I just requested a build of bittorrent-4_1_2-5_fc5; hope it's not too late ;-) This was one of the packages mysteriously failing to build in the old system (#159414), so it could be a useful test case. Paul. -- Paul Howarth From veillard at redhat.com Thu Jul 14 09:23:34 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 14 Jul 2005 05:23:34 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <002c01c5882f$2ccbee90$6a00a8c0@greybox> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> <20050713115228.GI8191@redhat.com> <1121279664.31100.1.camel@ignacio.lan> <20050713221705.GB8191@redhat.com> <002c01c5882f$2ccbee90$6a00a8c0@greybox> Message-ID: <20050714092334.GK8191@redhat.com> On Thu, Jul 14, 2005 at 12:47:43AM -0400, Mikhail S Grushinskiy wrote: > > > > Mikhail we are looking at integrating xmlstarlet in Fedora Core Extra > >but we have a couple of technical difficulties, > > > >https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00637.html > > > > your opinion would be welcome :-) > > > >Daniel > > > >-- > >Daniel Veillard | Red Hat Desktop team http://redhat.com/ > >veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > >http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > > > Daniel, > > I will work on configure scripts to link with shared libraries and renaming > executable Cool, better to have those changes made upstream :-), thanks a lot ! > in the next release. Is that a problem if you include both xsh and > xmlstarlet in distro? I don't think it's a problem. We are trying to avoid duplication in the Core set but one of Extras goals is precisely to preserve the diversity of the application space available to the users, so that should be just fine. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Thu Jul 14 09:27:11 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 14 Jul 2005 05:27:11 -0400 Subject: Request for Review: xmlstartlet In-Reply-To: <1121321621.2872.48.camel@localhost.localdomain> References: <1121123856.4423.8.camel@ignacio.lan> <20050712095349.GE7527@redhat.com> <1121207961.4423.33.camel@ignacio.lan> <20050713115228.GI8191@redhat.com> <1121279664.31100.1.camel@ignacio.lan> <20050713221705.GB8191@redhat.com> <1121321621.2872.48.camel@localhost.localdomain> Message-ID: <20050714092711.GL8191@redhat.com> On Thu, Jul 14, 2005 at 09:13:41AM +0300, Ville Skytt? wrote: > On Wed, 2005-07-13 at 18:17 -0400, Daniel Veillard wrote: > > Note that Ville Skytt? is pushing gdome2 to target xsh. In my opionion > > xsh and xmlstartlet are competing, both are wrappers around libxml2 to > > provide XML oriented scripting. I honnestly don't know which one might > > be better or more complete. > > Ah, I wasn't aware of xmlstartlet, need to take a look at it sometime. > If it makes it into Extras or libxml2/libxslt sooner than xsh, and > provides the same or "better" functionality, I could imagine dropping > pushing xsh. I think there is room for both. Actually if you could help do the spec/rpm review of xmlstarlet that would be nice you seems to be more aware than me of the Fedora Extras set of rules, thanks :-) > But I'm sure gdome2 will come in handy for other apps besides xsh. yes, I'm kind of surprized actually by the number of libxml2 and libxslt related add-ons I have seen proposed in the last 2 weeks. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alex at dalloz.de Thu Jul 14 10:36:14 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Thu, 14 Jul 2005 12:36:14 +0200 Subject: Request for review: keychain In-Reply-To: <3ab624bd0507130924669e3625@mail.gmail.com> References: <1121125939.1574.170.camel@serendipity.dogma.lan> <1121136584.4423.17.camel@ignacio.lan> <1121139513.1574.191.camel@serendipity.dogma.lan> <3ab624bd050711205432e6650e@mail.gmail.com> <1121266108.1574.298.camel@serendipity.dogma.lan> <1121267562.1574.305.camel@serendipity.dogma.lan> <3ab624bd0507130924669e3625@mail.gmail.com> Message-ID: <1121337374.1574.423.camel@serendipity.dogma.lan> Am Mi, den 13.07.2005 schrieb Chip Turner um 18:24: > > http://www.uni-x.org/keychain.sh.2.txt > > Overall a good start! But, this script is a bit complicated. Some comments: Thanks Chip! Though your words mean roughly "kick it to dust" ;> > 1) The differentiation between rsa keys, dsa keys, and gpg keys is a > bit unnecessary since they all end up on the command line anyway. I would say that at least a differentiation is necessary between dsa + rsa keys and gpg keys. Last ones need an additional tool (gpg-agent), which is not (yet) part of Core, but in gnupg2 from Extras. And the gpg keys has to be named by key ID number, while ssh keys can be loaded simply from file names. > 2) You can just use 'local FOO=""' instead of FOO="" and then worrying > about unsetting FOO. > > 3) Along with 2, you can have a 'set -u' that will require all vars > declared, thus ensuring you don't end up with FOOs that need localing > or unsetting that you didn't realize 2) and 3) noted. > 4) It would be nicer if a user just doing 'touch ~/.keychainrc' would > activate it. Creating empty configs for users who don't know anything > about keychain (maybe the admin just installed it for herself!) is > confusing, especially since it isn't done silently. Basically I'd > personally rather it be 'if keychainrc exists, set some defaults that > would load all the keys, then source the user's file letting them > override our defaults' and not 'require multiple settings in user's > config to have the system work properly' I must confess that from there I am starting to fail to see what's the user's gain or system's improvement from such kind of an opt-in. How would the user know that he has to touch a ~/.keychainrc or even how and which defaults to override? With respect to the said in 5) I can only imagine that the user has to read a readme or man page. But then he will be as quick to copy & paste the example code from "man 1 keychain" (enhanced by Ville's patch) for the different shells into his ~/.bash_profile or ~/.login. > 5) creating files in a user's homedir silently is naughty, esp for > software they've never ever run. I think thats debatable. There are so many hidden files and dirs (. | .) from programs / tools in the user's homedir which he hardly all know about, and each (?) tools creates them silently. > 6) The 'which keychain' is unnecessary since your script is part of > the keychain rpm -- one goes with the other :) Thats pretty correct :) > 7) chmod'ing to 640 is bad if a user has a umask of 077, etc. Thinking ... thinking ... can you please elaborate, Chip? You speak about the case, where a user explicitly wants that files in his home can not be read by the group? Would a "chmod 600" make things better or am I misunderstanding your comment? > 8) General scripting rule of thumb: when you nest four if loops deep, > something else is probably wrong. Don't want to be picky or to say my script suggestion is best you can think of, but frankly /etc/profile.d/lang.sh isn't much less complicated and has if I count correctly if clauses of 3 depth steps ;) And that thumb rule would disqualify the keychain wrapper script itself. > Chip Finally my suggestion: Taking what I commented to point 4) I would drop the idea of whatever kind of additional script and let the user, willing to make use of keychain, copy & paste what he needs into his profile file in home. He then certainly know if he wants to customize what keys will be loaded automatically at login. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From bugs.michael at gmx.net Thu Jul 14 10:48:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Jul 2005 12:48:43 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D6105C.4000204@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D5261F.9070401@linux-kernel.at> <20050713173051.1f10abef.bugs.michael@gmx.net> <200507132353.05654.symbiont@berlios.de> <42D6105C.4000204@linux-kernel.at> Message-ID: <20050714124843.1c9034a6.bugs.michael@gmx.net> On Thu, 14 Jul 2005 09:12:28 +0200, Oliver Falk wrote: > I also think, that the dist tag should always be added. Yes, there are > some packages, where you only install a script in a path that doesn't > change (eg. /etc), but to be sure, it's better to write the tag... > Especially, as Jeff mentions here, perl or python modules. You didn't give a rationale as why adding a dist tag would be "better". Mandatory dist tags give a false impression of upgrade-path safety. As long as Fedora Extras are not integrated into Anaconda, odd things with non-upgraded extra packages can still occur during firstboot and prior to the first yum upgrade/update. Mandatory dist tags also pretend that a src.rpm is dist-independent and can simply be rebuilt for older or newer distributions, respectively. This is not always true. Mandatory dist tags pretend that a binary rpm is distribution-specific and should not or must not be installed or used on a different distribution, even if a fully ABI compatible environment is available. Mandatory dist tags are no guarantee that an update package for an old distribution is always older [in EVR] than any package for newer distributions. Packagers still need to keep track of package release versions for all their released packages and updates. It is not always necessary to do mass-updates for all distributions if a bug only affects an older distribution. [...] With regard to dist-specific Python or Perl module packages, they are a bad example. In case Python really does an incompatible version jump between dist N and dist N+1 (e.g. as Python 2.3 to 2.4 did), such noarch packages need a rebuild, of course, so the new Python looks for the modules in the changed locations. If, however, the version does not jump like that, you end up with an old dist tag in your binary packages, which don't need a rebuild. Or you rebuild the packages just for cosmetic reasons (i.e. to get an updated dist tag and no important other changes). From jwboyer at jdub.homelinux.org Thu Jul 14 11:52:59 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 14 Jul 2005 06:52:59 -0500 Subject: buildsys status report In-Reply-To: <1121324355.13861.18.camel@cutter> References: <1121324355.13861.18.camel@cutter> Message-ID: <1121341980.2685.38.camel@yoda.jdub.homelinux.org> On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > Hi All, > Dan is the man and he has made it possible for things to work - and on > smp processors even! :) Long and short successful package builds have > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > things nice. Heck, I'll even throw in snails and puppy dog tails if > that's your kink. > Awesome! > Anyway - to do some more testing I'm going to push all the stuff in > tobuild through the system and see what comes out the other side. > > The next steps: > 1. get a list of all the extras committers/maintainers from Elliot and > push them into the plague authN db. > 2. write up the brief 'how do I use this' docs - this includes some > info about certs and other items you'll need. > 3. see if Dan is game for putting a version of plague IN extras so you, > the developer, can install plague-client. > 4. modify make build so it ends up calling plague-client > 5. work on getting a webpage status report dump from the buildsys. > 6. add new doodads and fix broken doodads. Any chance we could have: 7. release an Extras RPM update for the latest and greatest mock stuff It's been a while since that was updated... josh From andreas at bawue.net Thu Jul 14 12:38:37 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 14 Jul 2005 14:38:37 +0200 (CEST) Subject: A bunch of review-requests Message-ID: Hello, the following packages are still in need of review. If someone could please take a look at them and approve them, I'd be delighted. qsynaptics perl-Crypt-CBC perl-Crypt-Blowfish ddrescue dd_rescue dd_rhelp qsynaptics: QSynaptics aims to help desktop users to configure their synaptics touch pad that's commonly used in laptops. Currently it supports setting the following features: - pressure sensitivity: adjust how strong you have to press your pad to create events - tapping: adjustable tapping delay and disengageable tapping - smart tapping: switches off mouse pad for an certain delay after an keyboard event has occured - mouse button emulation: mapping of multifinger taps to certain mouse button - circular scrolling: enable or disable circular scrolling and adjusting the speed, configuring sensitive edges/corner SPEC: http://home.bawue.net/~ixs/qsynaptics/qsynaptics.spec SRPM: http://home.bawue.net/~ixs/qsynaptics/qsynaptics-0.21-1.src.rpm perl-Crypt-CBC: This is Crypt::CBC, a Perl-only implementation of the cryptographic cipher block chaining mode (CBC). In combination with a block cipher such as Crypt::DES or Crypt::IDEA, you can encrypt and decrypt messages of arbitrarily long length. The encrypted messages are compatible with the encryption format used by SSLeay. SPEC: http://home.bawue.net/~ixs/perl-Crypt-CBC/perl-Crypt-CBC.spec SRPM: http://home.bawue.net/~ixs/perl-Crypt-CBC/perl-Crypt-CBC-2.14-1.src.rpm perl-Crypt-Blowfish This is Crypt::Blowfish version 2.09, an XS-based implementation of the Blowfish cryptography algorithm designed by Bruce Schneier. It's designed to take full advantage of Crypt::CBC when desired. Blowfish keys may be up to 448 bits (56 bytes) long. Being an XS implimentation, Crypt::Blowfish is exceptionally faster than Blowfish_PP (a pure Perl implimentation). Internal testing displayed a difference of 400 times faster when doing complete cipher generation and encryption. Using a cached cipher resulted in 25 times faster than the pure Perl implimentation. (all machines idled prior to tests below) SPEC: http://home.bawue.net/~ixs/perl-Crypt-Blowfish/perl-Crypt-Blowfish.spec SRPM: http://home.bawue.net/~ixs/perl-Crypt-Blowfish/perl-Crypt-Blowfish-2.09-1.src.rpm ddrescue: GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying hard to rescue data in case of read errors. This makes it suitable for rescuing data from media with errors, e.g. a disk with bad sectors. SPEC: http://home.bawue.net/~ixs/ddrescue/ddrescue.spec SRPM: http://home.bawue.net/~ixs/ddrescue/ddrescue-1.0-2.src.rpm dd_rescue: Like dd, dd_rescue does copy data from one file or block device to another. You can specify file positions (called seek and Skip in dd). dd_rescue does however not abort on errors in the input file, which makes it suitable for rescuing data from a medium with errors, i.e. a hard disk with some bad sectors. SPEC: http://home.bawue.net/~ixs/dd_rescue/dd_rescue.spec SRPM: http://home.bawue.net/~ixs/dd_rescue/dd_rescue-1.11-2.src.rpm dd_rhelp: dd_rhelp will use ddrescue on your entire disc, but will try to gather the maximum valid data before trying for ages on badsectors. So if you leave dd_rhelp work for infinite time, it'll have the same effect as a simple dd_rescue. But because you might not have this infinite time (this could indeed take really long in some cases... ), dd_rhelp will jump over bad sectors and rescue valid data. In the long run, it'll parse all your device with dd_rescue. SPRC: http://home.bawue.net/~ixs/dd_rhelp/dd_rhelp.spec SRPM: http://home.bawue.net/~ixs/dd_rhelp/dd_rhelp-0.0.6-2.src.rpm A note about ddrescue/dd_rescue/dd_rhelp: There exist two fault tollerant dd solutions. One is named dd_rescue, the other is named ddrescue. Both have their pros and cons. dd_rescue together with dd_rhelp (a bash helper script) looks a bit more advanced then the GNU ddrescue, but this is my personal opinion. Problem was that there is currently a ddrescue package in the fedora-extras tree, which does package dd_rescue. This is a bit confusing, as there are people who'd like ddrescue as well. My suggestion to solve this mess is to include three packages, ddrescue, dd_rescue and dd_rhelp with correct epoch and conflict tags to fix the naming mess. TIA, andreas From mattdm at mattdm.org Thu Jul 14 14:12:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 10:12:58 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> Message-ID: <20050714141258.GA9982@jadzia.bu.edu> On Wed, Jul 13, 2005 at 11:59:33PM -0400, Chris Ricker wrote: > Some observations: > * categorization takes longer than you'd expect ;-) > * there are some categories which seem overly broad; system-tools for > example could be broken up more > * some stuff didn't fit any existing categories (allegro-tools, for one) > Thoughts? I think there's two distinct purposes for which people want to use groups: A) a way to put similar programs in the same place so they're easy to find by browsing B) a way to define sets of programs useful for a particular environment or task The first is generally what one wants in repoview or in a GUI package tool when looking for a particular program. The second is what is probably best in the installer, and maybe also useful in an after-install GUI tool. The original in-spec groups are more geared to the first, and the current comps.xml more to the second -- with some fuzziness in both cases. The problem is that these two different purposes want groups that look very different. For the second, a group of all web browsers is basically stupid -- whereas if you want to see what web browsers are available and choose one or more, it's exactly what you want. And also for the second purpose, it's perfectly okay for some or even most packages to not be listed -- but that's very frustrating for the first. This makes me think that categorization may be better approached via "tagging", and then different applications could present different views of the tags as appropriate. For example, various web browsers could have tags like this: firefox: Web Browser, X11, Typical Desktop, Internet Station dillo: Web Browser, X11, Lightweight Desktop epiphany: Web Browser, X11, GNOME konqueror: Web Browser, X11, KDE lynx: Web Browser, Console, Visually Impaired Desktop elinks: Web Browser, Console (Or whatever -- that's off the top of my head.) And then, repoview and other package browsers could present all web browsers neatly together, whereas the installer could present groups like "Typical Desktop". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From jscott at skynet.be Thu Jul 14 14:22:55 2005 From: jscott at skynet.be (Jan Scott) Date: Thu, 14 Jul 2005 16:22:55 +0200 Subject: wine for fedora core 4? Message-ID: <1121350975.3618.3.camel@localhost.localdomain> Hello, I use fedora core 4 and want to install wine. But there are only rpm's available for fedora core 1 , 2 , 3. Is it safe to use the rpm corresponding with fedora core 3? Thanks Jan From oliver at linux-kernel.at Thu Jul 14 14:42:07 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 16:42:07 +0200 Subject: wine for fedora core 4? In-Reply-To: <1121350975.3618.3.camel@localhost.localdomain> References: <1121350975.3618.3.camel@localhost.localdomain> Message-ID: <42D679BF.80608@linux-kernel.at> On 07/14/2005 04:22 PM, Jan Scott wrote: > I use fedora core 4 and want to install wine. But there are only rpm's > available for fedora core 1 , 2 , 3. > Is it safe to use the rpm corresponding with fedora core 3? Strange this is, there is an empty wine dir in extras devel repo: [oliver at moon extras] ls wine/ CVS But for branch FC-3, RHL-9, there are the files (just checked 'em out) and owners.list tells me, who is the owner: [oliver at moon owners]$ grep wine owners.list Fedora Extras|wine|A Windows 16/32 bit emulator|pmatilai at laiskiainen.org So it seems, the branch was made, but the files never copied and so no build was requested yet... Best, Oliver From oliver at linux-kernel.at Thu Jul 14 14:46:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 16:46:57 +0200 Subject: wine for fedora core 4? In-Reply-To: <1121350975.3618.3.camel@localhost.localdomain> References: <1121350975.3618.3.camel@localhost.localdomain> Message-ID: <42D67AE1.4070404@linux-kernel.at> On 07/14/2005 04:22 PM, Jan Scott wrote: > I use fedora core 4 and want to install wine. But there are only rpm's > available for fedora core 1 , 2 , 3. > Is it safe to use the rpm corresponding with fedora core 3? And no, I don't think it's safe to use those rpms, as the source that was used is: Wine-20030911.tar.gz ^^^^^^^^ Pretty old, isn't it? :-/ Best, Oliver From ermeyers at adelphia.net Thu Jul 14 14:50:41 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Thu, 14 Jul 2005 10:50:41 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507141053.08707.ermeyers@adelphia.net> On 7/9/05 Jeff Spaleta wrote: >yum --disablerepo=extras-development groupinfo "Editors" >... First, here is the "Editors" group as listed in the comps.xml file, with the 'xml:lang' localization tags removed for clarity: editors Editors Sometimes called text editors, these are programs that allow you to create and edit files. These include Emacs and Vi. false true base xemacs jed leafpad TeXmacs Now, yum --disablerepo=extras-development groupinfo "Editors": yum --disablerepo=extras-development groupinfo "Editors" Setting up Group Process Setting up repositories Group: Editors Required Groups: Base Optional Metapkgs: XEmacs Emacs Default Packages: vim-enhanced Optional Packages leafpad TeXmacs jed joe vim-X11 This output is slightly different than what Jeff provided in https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00479.html From the "group list" spec in the xml, one can clearly see why base is included as a "required group," xemacs is included as a "optional metapkg." From the "package list" spec in the xml, it is also clear why we see jed, leafpad and TeXmacs included in "optional packages." I don't understand how vim-enhanced is listed as a "default package," nor do I understand how joe and vim-X11 show up as "optional packages." Maybe someone from redhat could send me the comps.dtd with some tag documentation, because I also don't know the complete meaning of the and tags. Organizational progress is being made though, and that will be another posting. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Thu Jul 14 15:08:17 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 14 Jul 2005 16:08:17 +0100 Subject: wine for fedora core 4? In-Reply-To: <42D67AE1.4070404@linux-kernel.at> References: <1121350975.3618.3.camel@localhost.localdomain> <42D67AE1.4070404@linux-kernel.at> Message-ID: <1121353697.4946.41.camel@localhost> Hi, > On 07/14/2005 04:22 PM, Jan Scott wrote: > > I use fedora core 4 and want to install wine. But there are only rpm's > > available for fedora core 1 , 2 , 3. > > Is it safe to use the rpm corresponding with fedora core 3? > > And no, I don't think it's safe to use those rpms, as the source that > was used is: Wine-20030911.tar.gz > ^^^^^^^^ Pretty old, isn't it? :-/ I've just tried to build the current FC3 srpm and it won't build. I'm trying to make an RPM of the current tarball and will let folks know if and when it's ready. TTFN Paul -- "The city of Washington was built on a stagnant swamp some 200 years ago and very little has changed; it stank then and it stinks now. Only today, it is the fetid stench of corruption that hangs in the air" - Simpson, L. Mr Lisa Goes to Washington (1991) Fox. 8F01 (Sep). From kaboom at oobleck.net Thu Jul 14 15:15:47 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 11:15:47 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141053.08707.ermeyers@adelphia.net> References: <200507141053.08707.ermeyers@adelphia.net> Message-ID: On Thu, 14 Jul 2005, Eric R. Meyers wrote: > I don't understand how vim-enhanced is listed as a "default package," nor do I > understand how joe and vim-X11 show up as "optional packages." It's merged them in from comps.xml for FC "editor" for FC is joe nedit vim-X11 vim-enhanced > Maybe someone from redhat could send me the comps.dtd with some tag > documentation, because I also don't know the complete meaning of the > and tags. uservisible is whether it's an exposed group or not (think all groups that exist in comps.xml versus groups shown by, say, anaconda). For example, in FC there's a "core" group that's not exposed that serves as a basis for the base group that's the smallest exposed grouping.... optional means it's not installed by default even if the group's installed mandatory means if that group's installed, that package will be installed default means if that group's installed, that package will be installed by default, but it can be deselected So, if you went in your editor group on FC you'd see vim-enhanced selected to install, but you could deselect it. And you'd see joe, nedit, and vim-X11 deselected, but you could select them. later, chris From adrian at lisas.de Thu Jul 14 15:22:52 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 14 Jul 2005 17:22:52 +0200 Subject: Request for Review: Rekall and dependencies In-Reply-To: <1121023144.22400.57.camel@localhost.localdomain> References: <1119238318.11411.8.camel@localhost.localdomain> <20050710165355.GA16609@lisas.de> <1121023144.22400.57.camel@localhost.localdomain> Message-ID: <20050714152252.GB10688@lisas.de> On Sun, Jul 10, 2005 at 02:19:04PM -0500, Tom 'spot' Callaway wrote: > On Sun, 2005-07-10 at 18:53 +0200, Adrian Reber wrote: > > On Sun, Jun 19, 2005 at 10:31:58PM -0500, Tom 'spot' Callaway wrote: > > > SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-1.src.rpm > > > SPEC: http://auroralinux.org/people/spot/review/xbsql.spec > > > > Doesn't build in mock without BR: ncurses-devel > > The description is very long. A shorter one without every feature > > described int detail would be much nicer. > > Both items fixed: > > SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-2.src.rpm > SPEC: http://auroralinux.org/people/spot/review/xbsql.spec > > Please re-review/approve. Thanks, readline-devel is also required as BR Adrian From katzj at redhat.com Thu Jul 14 15:25:52 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 14 Jul 2005 11:25:52 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141053.08707.ermeyers@adelphia.net> References: <200507141053.08707.ermeyers@adelphia.net> Message-ID: <1121354752.15082.6.camel@bree.local.net> On Thu, 2005-07-14 at 10:50 -0400, Eric R. Meyers wrote: > Maybe someone from redhat could send me the comps.dtd with some tag > documentation, because I also don't know the complete meaning of the > and tags. There isn't an official DTD. The documentation (though somewhat outdated) which exists is at http://rhlinux.redhat.com/anaconda/comps.html. You can ignore the section about "Generating the full comps file" and the section as those aren't relevant anymore. > Organizational progress is being made though, and that will be another > posting. Awesome! Jeremy From kaboom at oobleck.net Thu Jul 14 15:23:59 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 11:23:59 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714141258.GA9982@jadzia.bu.edu> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> Message-ID: On Thu, 14 Jul 2005, Matthew Miller wrote: > I think there's two distinct purposes for which people want to use groups: > > A) a way to put similar programs in the same place so they're > easy to find by browsing > > B) a way to define sets of programs useful for a particular environment > or task > > The first is generally what one wants in repoview or in a GUI package tool > when looking for a particular program. > > The second is what is probably best in the installer, and maybe also useful > in an after-install GUI tool. Yep. And a related issue is the mandatory / default / optional stuff. (almost) all Extras stuff is added as type=optional. For some situations that makes sense, but for others default would be nicer. You probably want yum groupinstall games to install all games (default) but you probably do not want yum groupinstall mail-server not to install all 3 MTAs (optional) > This makes me think that categorization may be better approached via > "tagging", and then different applications could present different views of > the tags as appropriate. For example, various web browsers could have tags > like this: > > firefox: Web Browser, X11, Typical Desktop, Internet Station > dillo: Web Browser, X11, Lightweight Desktop > epiphany: Web Browser, X11, GNOME > konqueror: Web Browser, X11, KDE > lynx: Web Browser, Console, Visually Impaired Desktop > elinks: Web Browser, Console > > (Or whatever -- that's off the top of my head.) How is tagging functionally different from spec groups (other than allowing more than one tag)? Isn't the spec group just a very coarse tag? later, chris From kaboom at oobleck.net Thu Jul 14 15:26:55 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 11:26:55 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> Message-ID: On Thu, 14 Jul 2005, Chris Ricker wrote: > situations that makes sense, but for others default would be nicer. You > probably want yum groupinstall games to install all games (default) but > you probably do not want yum groupinstall mail-server not to install all 3 > MTAs (optional) Oops, that should be you probably do not want yum groupinstall mail-server to install all 3 MTAs.... /me backs slowly away from the keyboard ;-) later, chris From paul at all-the-johnsons.co.uk Thu Jul 14 15:32:00 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 14 Jul 2005 16:32:00 +0100 Subject: wxWidgets? Message-ID: <1121355120.4946.43.camel@localhost> Hi, Is it possible to have an updated version of wxWidgets uploaded. The 2.4 branch is getting a bit long in the tooth. TTFN Paul -- "The city of Washington was built on a stagnant swamp some 200 years ago and very little has changed; it stank then and it stinks now. Only today, it is the fetid stench of corruption that hangs in the air" - Simpson, L. Mr Lisa Goes to Washington (1991) Fox. 8F01 (Sep). -------------- 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 jspaleta at gmail.com Thu Jul 14 15:33:16 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 11:33:16 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714141258.GA9982@jadzia.bu.edu> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> Message-ID: <604aa7910507140833518e955e@mail.gmail.com> On 7/14/05, Matthew Miller wrote: > This makes me think that categorization may be better approached via > "tagging", and then different applications could present different views of > the tags as appropriate. For example, various web browsers could have tags > like this: If I may re-interpret "tagging"... this sounds like the the "trove" model as implemented by freshmeat. -jef From ville.skytta at iki.fi Thu Jul 14 15:37:24 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 18:37:24 +0300 Subject: wxWidgets? In-Reply-To: <1121355120.4946.43.camel@localhost> References: <1121355120.4946.43.camel@localhost> Message-ID: <1121355444.2872.75.camel@localhost.localdomain> On Thu, 2005-07-14 at 16:32 +0100, Paul wrote: > Is it possible to have an updated version of wxWidgets uploaded. The 2.4 > branch is getting a bit long in the tooth. https://bugzilla.redhat.com/154618 From pnasrat at redhat.com Thu Jul 14 15:43:16 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 14 Jul 2005 11:43:16 -0400 Subject: No more right click terminal In-Reply-To: <1121300226.3826.31.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> Message-ID: <1121355796.3094.18.camel@enki.eridu> On Wed, 2005-07-13 at 20:17 -0400, Paul W. Frields wrote: > On Wed, 2005-07-13 at 15:42 -0700, Jesse Keating wrote: > > On Wed, 2005-07-13 at 13:00 -0400, Colin Walters wrote: > > > Someone should just package nautilus-open-terminal, which AFAICS should > > > address the vast majority of complaints in this thread. > > > > If nobody gets to it by the time I"m done w/ my book editing, I'll look > > at it. > I hesitate to speak up in the presence of people far more experienced > than I, but I did a quick one that anyone is free to criticize, steal, > and/or adopt. > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > Please be gentle, I'm just a doc writer. :-D Move to extras list. Please keep Paul Frields CC'd in case he hasn't subscribed yet. Paul check out the Extras docs here http://fedoraproject.org/wiki/Extras for how to get this in. Paul From ermeyers at adelphia.net Thu Jul 14 15:57:15 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Thu, 14 Jul 2005 11:57:15 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507141157.34063.ermeyers@adelphia.net> Gentlemen, and those "other" I've read through the thread of messages, and I've studied Repoview, and I've got somewhat of a handle on comps.xml. Also, I've learned a little about yum. One of the first things that Seth Vidal said to me was "focus groups based around what people want to do." And that's what we are going to do in fedora-extras. What do people want to do? How about, "they want to use yum to download stuff." So, the paradigm is to support yum functionality, as many ways (views) as possible. At this point Repoview provides two primary views of packages 1. Alphabetical grouping 2. Fuzzy typal grouping (with the possible exception of the XFCE groups) What Repoview does should simply be ignored. What we want to provide is clear (unfuzzy) grouping with multiple views of the packages, depending on what the user wants to do, or how that user wants to access, review or remove the packages. So here are the major views: 1. Alphabetical grouping (I want to look at all packages that start with 'a') 2. Typal grouping (I want a small web-server)(or small web-server-accessory) 3. Logical grouping (I want to install a suite of packages for ...) Comments Appreciated. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From i.pilcher at comcast.net Thu Jul 14 15:56:52 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 14 Jul 2005 10:56:52 -0500 Subject: wine for fedora core 4? In-Reply-To: <1121353697.4946.41.camel@localhost> References: <1121350975.3618.3.camel@localhost.localdomain> <42D67AE1.4070404@linux-kernel.at> <1121353697.4946.41.camel@localhost> Message-ID: Paul F. Johnson wrote: > I've just tried to build the current FC3 srpm and it won't build. I'm > trying to make an RPM of the current tarball and will let folks know if > and when it's ready. You may want to take a look at http://home.comcast.net/~i.pilcher/wine-0.20050706cvs-1fc4babel.src.rpm (Uploading over a slow link now, so give it a few minutes.) HTH -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From andreas at bawue.net Thu Jul 14 16:10:46 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 14 Jul 2005 18:10:46 +0200 (CEST) Subject: Request for review: scmxx Message-ID: Hello, I've packaged scmxx for extras and would like someone to review the resulting spec. SCMxx is a console program that allows you to exchange certain types of data with mobile phones made by Siemens. Some of the data types that can be exchanged are logos, ring tones, vCalendars, phonebook entries, and short messages. Other actions like setting the time and dialling a number are also possible. SPEC: http://home.bawue.net/~ixs/scmxx/scmxx.spec SRPM: http://home.bawue.net/~ixs/scmxx/scmxx-0.8.0-1.src.rpm The package builds in mock and rpmlint shows no errors or warnings. thx, andreas From mattdm at mattdm.org Thu Jul 14 16:11:46 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 12:11:46 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> Message-ID: <20050714161146.GA14554@jadzia.bu.edu> On Thu, Jul 14, 2005 at 11:23:59AM -0400, Chris Ricker wrote: > How is tagging functionally different from spec groups (other than > allowing more than one tag)? Isn't the spec group just a very coarse tag? Allowing more than one tag is the fuctional difference. :) Plus, I don't think the tags would have an inherent hierarchy. There may also be good reasons to keep these tags completely out of the spec files and managed externally a la comps.xml (but I'm not convinced). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From mattdm at mattdm.org Thu Jul 14 16:15:18 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 12:15:18 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507140833518e955e@mail.gmail.com> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <604aa7910507140833518e955e@mail.gmail.com> Message-ID: <20050714161518.GB14554@jadzia.bu.edu> On Thu, Jul 14, 2005 at 11:33:16AM -0400, Jeff Spaleta wrote: > > This makes me think that categorization may be better approached via > > "tagging", and then different applications could present different views of > > the tags as appropriate. For example, various web browsers could have tags > > like this: > If I may re-interpret "tagging"... this sounds like the the "trove" > model as implemented by freshmeat. Yes indeed. Although I don't think they have existing categories to cover the "best of breed for a given purpose" grouping (like "Typical Desktop"). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From tanaji_yadav at yahoo.com Thu Jul 14 16:28:23 2005 From: tanaji_yadav at yahoo.com (tanaji yadav) Date: Thu, 14 Jul 2005 09:28:23 -0700 (PDT) Subject: rpmdb not found Message-ID: <20050714162823.14398.qmail@web34404.mail.mud.yahoo.com> i have installed fedora 4 but there isnt any rpmdb-fedora rpm so i cant run rpm command with --aid option. pls help Regards Tanaji Yadav (RHCE) Executive - System And Network Administration ---------------------------------- NavinMail Services (India) Samruddhi Venture park, 4th Floor MIDC, Andheri (E), Mumbai 400 093 Dir - (+22) 2831 6642 Mob - [+91] 98674 18654 Board - (+22) 2831 6565 Ext 178 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Thu Jul 14 16:33:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 12:33:32 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141157.34063.ermeyers@adelphia.net> References: <200507141157.34063.ermeyers@adelphia.net> Message-ID: <20050714163332.GC14554@jadzia.bu.edu> On Thu, Jul 14, 2005 at 11:57:15AM -0400, Eric R. Meyers wrote: > One of the first things that Seth Vidal said to me was "focus groups based > around what people want to do." And that's what we are going to do in > fedora-extras. Check out my recent post in another branch of this thread.... I think Seth means "purpose B": B) a way to define sets of programs useful for a particular environment or task Where "what people want to do" is "what people want to do with their computers, not caring about the details of package management blah blah blah". > What do people want to do? How about, "they want to use yum to download > stuff." So, the paradigm is to support yum functionality, as many ways > (views) as possible. Whereas this interpretation is "what people want to do when they're lookin' for packages" -- more closely aligned with A) a way to put similar programs in the same place so they're easy to find by browsing > So here are the major views: [reformatted long lines a bit...] > 1. Alphabetical grouping (I want to look at all packages that start > with 'a') > 2. Typal grouping (I want a small web-server)(or small > web-server-accessory) > 3. Logical grouping (I want to install a suite of packages for ...) In other words, your 2 = my A and your 3 = my B. :) Debian calls the "logical groupings" Tasks, and in Anaconda, they're Components. (In both cases, kind of fuzzily bleeding into the "typal grouping" sometimes.) I think Component is a actually a really great term for this -- you build a system by taking the parts you need for your purpose and put 'em together. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From bugs.michael at gmx.net Thu Jul 14 16:45:29 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Jul 2005 18:45:29 +0200 Subject: wine for fedora core 4? In-Reply-To: <42D679BF.80608@linux-kernel.at> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> Message-ID: <20050714184529.4e809498.bugs.michael@gmx.net> On Thu, 14 Jul 2005 16:42:07 +0200, Oliver Falk wrote: > On 07/14/2005 04:22 PM, Jan Scott wrote: > > I use fedora core 4 and want to install wine. But there are only rpm's > > available for fedora core 1 , 2 , 3. > > Is it safe to use the rpm corresponding with fedora core 3? > > Strange this is, there is an empty wine dir in extras devel repo: > > [oliver at moon extras] ls wine/ > CVS > > But for branch FC-3, RHL-9, there are the files (just checked 'em out) > and owners.list tells me, who is the owner: > > [oliver at moon owners]$ grep wine owners.list > Fedora Extras|wine|A Windows 16/32 bit emulator|pmatilai at laiskiainen.org > > So it seems, the branch was made, but the files never copied and so no > build was requested yet... "devel" is not a branch, FC-4, FC-3 and older are. If a package is discontinued, the first place where to delete the files is "devel". "devel" only contained wine because devel is where a module is started before it's branched. The version of wine that was imported is from rh9 times and was branched by accident. Have a look at "cvs log". -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1432_FC5 loadavg: 1.07 1.08 0.59 From paul at all-the-johnsons.co.uk Thu Jul 14 16:46:11 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 14 Jul 2005 17:46:11 +0100 Subject: wine for fedora core 4? In-Reply-To: References: <1121350975.3618.3.camel@localhost.localdomain> <42D67AE1.4070404@linux-kernel.at> <1121353697.4946.41.camel@localhost> Message-ID: <1121359571.4946.46.camel@localhost> Hi, > > I've just tried to build the current FC3 srpm and it won't build. I'm > > trying to make an RPM of the current tarball and will let folks know if > > and when it's ready. > > You may want to take a look at > > http://home.comcast.net/~i.pilcher/wine-0.20050706cvs-1fc4babel.src.rpm No harm in both of us having it, though your version is slightly newer than mine (it's based on the source release on the 28th June). The version you're pointing to there may be better for rawhide users, mine is for FC4 stable users. TTFN Paul -- "The city of Washington was built on a stagnant swamp some 200 years ago and very little has changed; it stank then and it stinks now. Only today, it is the fetid stench of corruption that hangs in the air" - Simpson, L. Mr Lisa Goes to Washington (1991) Fox. 8F01 (Sep). From ville.skytta at iki.fi Thu Jul 14 16:58:52 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 19:58:52 +0300 Subject: Review: perl-Crypt-Blowfish / CBC In-Reply-To: References: Message-ID: <1121360332.2872.99.camel@localhost.localdomain> On Wed, 2005-07-13 at 02:00 +0200, Andreas Thienemann wrote: > I packaged two crypt related perl packages. Approved with the attached patches/remarks below taken care of: > SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-CBC/ Need to own one more dir, and eg/ is referred to in the docs, so it would be good to include it. See patch. > SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-Blowfish/ Need to own one more dir, honor $RPM_OPT_FLAGS, non-empty *.bs must not be deleted, improve summary and description, trim build deps. See patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Crypt-CBC.spec.patch Type: text/x-patch Size: 309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-Crypt-Blowfish.spec.patch Type: text/x-patch Size: 2147 bytes Desc: not available URL: From pnasrat at redhat.com Thu Jul 14 16:59:27 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 14 Jul 2005 12:59:27 -0400 Subject: rpmdb not found In-Reply-To: <20050714162823.14398.qmail@web34404.mail.mud.yahoo.com> References: <20050714162823.14398.qmail@web34404.mail.mud.yahoo.com> Message-ID: <1121360368.3094.21.camel@enki.eridu> On Thu, 2005-07-14 at 09:28 -0700, tanaji yadav wrote: > i have installed fedora 4 but there isnt any rpmdb-fedora rpm so i > cant run rpm command with --aid option. > pls help This is the wrong list - please use fedora-list for end user questions. rpmdb-fedora has been deprecated instead use yum and yum-utils from extras for multi repository and update driven dependency solving. Paul From kaboom at oobleck.net Thu Jul 14 16:59:46 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 12:59:46 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714161146.GA14554@jadzia.bu.edu> References: <200507081332.58353.ermeyers@adelphia.net> <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> Message-ID: On Thu, 14 Jul 2005, Matthew Miller wrote: > On Thu, Jul 14, 2005 at 11:23:59AM -0400, Chris Ricker wrote: > > How is tagging functionally different from spec groups (other than > > allowing more than one tag)? Isn't the spec group just a very coarse tag? > > Allowing more than one tag is the fuctional difference. :) Plus, I don't > think the tags would have an inherent hierarchy. Okay > There may also be good reasons to keep these tags completely out of the spec > files and managed externally a la comps.xml (but I'm not convinced). I don't see much advantage to having tags in the spec file, and several disadvantages. Two big reasons for doing it external: 1. it's not Yet More Crap in the spec file that will rot over time, but forever more be needed (like the current spec Group) 2. it can be revised as needed, and retrofitted to existing packages, without rebuilding the world About the only reason I can think of for doing it in the spec is simplicity later, chris From andreas at bawue.net Thu Jul 14 17:07:17 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 14 Jul 2005 19:07:17 +0200 (CEST) Subject: Review: perl-Crypt-Blowfish / CBC In-Reply-To: <1121360332.2872.99.camel@localhost.localdomain> References: <1121360332.2872.99.camel@localhost.localdomain> Message-ID: Hello, On Thu, 14 Jul 2005, Ville Skytt? wrote: > > I packaged two crypt related perl packages. > Approved with the attached patches/remarks below taken care of: Thanks. > > SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-CBC/ > Need to own one more dir, and eg/ is referred to in the docs, so it > would be good to include it. See patch. Kay. > > SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-Blowfish/ > Need to own one more dir, honor $RPM_OPT_FLAGS, non-empty *.bs must not > be deleted, improve summary and description, trim build deps. See > patch. Uhm. Sure about the non-empty stuff? rpmlint complains about them and on #fedora-extra I was advised to delete them. bye, andreas From jspaleta at gmail.com Thu Jul 14 17:08:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 13:08:02 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714163332.GC14554@jadzia.bu.edu> References: <200507141157.34063.ermeyers@adelphia.net> <20050714163332.GC14554@jadzia.bu.edu> Message-ID: <604aa79105071410087a380e3d@mail.gmail.com> On 7/14/05, Matthew Miller wrote: > Debian calls the "logical groupings" Tasks, and in Anaconda, they're > Components. (In both cases, kind of fuzzily bleeding into the "typal > grouping" sometimes.) I think Component is a actually a really great term > for this -- you build a system by taking the parts you need for your purpose > and put 'em together. You aren't the only one you likes the term component. http://componentizedlinux.org/ http://componentizedlinux.org/documentation/component-model/ From kaboom at oobleck.net Thu Jul 14 17:14:12 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 13:14:12 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141157.34063.ermeyers@adelphia.net> References: <200507141157.34063.ermeyers@adelphia.net> Message-ID: On Thu, 14 Jul 2005, Eric R. Meyers wrote: > So here are the major views: > 1. Alphabetical grouping (I want to look at all packages that start with 'a') > 2. Typal grouping (I want a small web-server)(or small web-server-accessory) > 3. Logical grouping (I want to install a suite of packages for ...) > > Comments Appreciated. I think that's all doable with current comps (1) doesn't require comps at all (2) would be groups which list related apps, most type="optional", best-of-breed one type="default" (3) would be groups which list related apps, most type="default" For (2) vs (3), are you envisioning categorizing all of Fedora space twice (once into type-2 groups, once into type-3 groups), or are you envisioning careful group creation (web-server as a type-2 group, games as a type-3 group)? later, chris From mattdm at mattdm.org Thu Jul 14 17:23:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 13:23:10 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> Message-ID: <20050714172310.GA17720@jadzia.bu.edu> On Thu, Jul 14, 2005 at 12:59:46PM -0400, Chris Ricker wrote: > Two big reasons for doing it external: > 1. it's not Yet More Crap in the spec file that will rot over time, but > forever more be needed (like the current spec Group) Well, since the current group tag is already Forever More Needed, we might as well reuse it for this. > 2. it can be revised as needed, and retrofitted to existing packages, > without rebuilding the world An advantage over the tag/trove approach over the old groups scheme is that the hierarchy and display would be kept as external, so most sorts of retrofitting wouldn't require rebuild. Keeping the tag information in an external file has the converse problem: every time you want to change (or worse, add) a package, someone has got to edit the file. And I don't think we want to have a .metadata file for every package, so it's likely to be Some Central File. > About the only reason I can think of for doing it in the spec is > simplicity Exactly. And don't underestimate simplicity. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From mattdm at mattdm.org Thu Jul 14 17:23:52 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 13:23:52 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa79105071410087a380e3d@mail.gmail.com> References: <200507141157.34063.ermeyers@adelphia.net> <20050714163332.GC14554@jadzia.bu.edu> <604aa79105071410087a380e3d@mail.gmail.com> Message-ID: <20050714172352.GB17720@jadzia.bu.edu> On Thu, Jul 14, 2005 at 01:08:02PM -0400, Jeff Spaleta wrote: > > Debian calls the "logical groupings" Tasks, and in Anaconda, they're > > Components. (In both cases, kind of fuzzily bleeding into the "typal > > grouping" sometimes.) I think Component is a actually a really great term > > for this -- you build a system by taking the parts you need for your purpose > > and put 'em together. > You aren't the only one you likes the term component. > http://componentizedlinux.org/ > http://componentizedlinux.org/documentation/component-model/ Yeah, I'm aware. But RH/Fedora used it first. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From mattdm at mattdm.org Thu Jul 14 17:27:03 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 13:27:03 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507141157.34063.ermeyers@adelphia.net> Message-ID: <20050714172703.GC17720@jadzia.bu.edu> On Thu, Jul 14, 2005 at 01:14:12PM -0400, Chris Ricker wrote: > I think that's all doable with current comps > (1) doesn't require comps at all > (2) would be groups which list related apps, most type="optional", > best-of-breed one type="default" > (3) would be groups which list related apps, most type="default" Yeah, this would be one approach. I think it'd be extremely useful to have something which distinguishes between the two types of groups, though. > For (2) vs (3), are you envisioning categorizing all of Fedora space twice > (once into type-2 groups, once into type-3 groups), or are you envisioning > careful group creation (web-server as a type-2 group, games as a type-3 > group)? I think basically one and a half, or 1.2x -- everything into one or more type-based category, and carefully selected programs into "Component" groups. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From kaboom at oobleck.net Thu Jul 14 17:29:34 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 13:29:34 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714172310.GA17720@jadzia.bu.edu> References: <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> Message-ID: On Thu, 14 Jul 2005, Matthew Miller wrote: > On Thu, Jul 14, 2005 at 12:59:46PM -0400, Chris Ricker wrote: > > Two big reasons for doing it external: > > 1. it's not Yet More Crap in the spec file that will rot over time, but > > forever more be needed (like the current spec Group) > > Well, since the current group tag is already Forever More Needed, we might > as well reuse it for this. If it goes in the spec at all, sure. But is Group abusable to get multiple tags? And if you're having to make changes to get Group usable, why not just kill it instead? > > 2. it can be revised as needed, and retrofitted to existing packages, > > without rebuilding the world > > An advantage over the tag/trove approach over the old groups scheme is that > the hierarchy and display would be kept as external, so most sorts of > retrofitting wouldn't require rebuild. retrofitting's needed in the sense of something has to have a tag to be categorizable. So if the tag is within the rpm, all the existing rpms either need a rebuild (not going to happen, except perhaps for the sphere of Fedora) or you have to fall back to the existing meaningless Group tag I agree that revision of tags, once in place, hopefully wouldn't be needed much because all the logic is external to the tag.... > Keeping the tag information in an external file has the converse problem: > every time you want to change (or worse, add) a package, someone has got to > edit the file. And I don't think we want to have a .metadata file for every > package, so it's likely to be Some Central File. But Some Central File has to change anyway every time packages change, are added, etc. That's a solved problem.... > > About the only reason I can think of for doing it in the spec is > > simplicity > > Exactly. And don't underestimate simplicity. :) Sure. I just don't see any pressing need for that info to be within the spec.... later, chris From mattdm at mattdm.org Thu Jul 14 17:45:08 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 13:45:08 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> Message-ID: <20050714174508.GA18864@jadzia.bu.edu> On Thu, Jul 14, 2005 at 01:29:34PM -0400, Chris Ricker wrote: > > Well, since the current group tag is already Forever More Needed, we might > > as well reuse it for this. > If it goes in the spec at all, sure. But is Group abusable to get multiple > tags? And if you're having to make changes to get Group usable, why not > just kill it instead? You don't have to make changes -- you can put pretty much any arbitrary string there. > retrofitting's needed in the sense of something has to have a tag to be > categorizable. So if the tag is within the rpm, all the existing rpms > either need a rebuild (not going to happen, except perhaps for the sphere > of Fedora) or you have to fall back to the existing meaningless Group tag Yeah; the existing groups could be recogized by the way they contain a "/" and dealt with as legacy. Or, maybe it wouldn't be considered a tag unless there's more than one separated by a ",". Or just let 'em be tags that would generally be ignored. So many possibilities. :) > > Keeping the tag information in an external file has the converse problem: > > every time you want to change (or worse, add) a package, someone has got to > > edit the file. And I don't think we want to have a .metadata file for every > > package, so it's likely to be Some Central File. > But Some Central File has to change anyway every time packages change, are > added, etc. That's a solved problem.... How so? You mean the yum repo metadata? That's automatically generated from info in the RPMs themselves.... > > > About the only reason I can think of for doing it in the spec is > > > simplicity > > Exactly. And don't underestimate simplicity. :) > Sure. I just don't see any pressing need for that info to be within the > spec.... I could be convinced, but on the contrary, I don't see any pressing need for it *not* to be, given a better design than the old "GROUPS" list. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From fedora at tqmcube.com Thu Jul 14 17:45:57 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Thu, 14 Jul 2005 13:45:57 -0400 Subject: New Package Process Documentation Message-ID: <1121363158.2390.62.camel@dch.TQMcube.com> IF it's needed, I was thinking about writing a supplementary how-to. Personally, I've struggled a bit. For example, I seem to have missed the part about publishing the GPG key to a keyserver before I could finalize CVS access. Of course, it very well could be just me. That's OK since I have much to learn. OTOH, there MIGHT be a problem with the documentation. If you have personally encountered some difficulties getting up to speed as a maintainer, please contact me off list at davidREMOVEMEhart at tqmcube.com . Perhaps I can catalog the issues - perhaps not or perhaps there are none. If you are interested, other How-To docs that I have done are here: http://tqmcube.com/linux_diversions.htm. BTW, thanks to Michael and others who have been astonishingly patient. So far, this has been a great and challenging experience for me. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From bugs.michael at gmx.net Thu Jul 14 17:52:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Jul 2005 19:52:50 +0200 Subject: FETarget5 tracker bug Message-ID: <20050714195250.70465c37.bugs.michael@gmx.net> FC5 is still far away. But since some of the fixes for Fedora Extras 4 have been somewhat belated [with a very few not fixed yet], here's the "FE5Target" tracker bug early: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162161 https://bugzilla.redhat.com/162161 Just like with the FE4Target tracker bug, it should track issues, which users and/or developers would like to see fixed, for the next distribution release at last. This includes things which affect the current release, as well as persistent bugs and defects which are due to dependencies on other packages [in Core or Extras] or on upstream work. From skvidal at phy.duke.edu Thu Jul 14 18:03:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 14:03:16 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714172310.GA17720@jadzia.bu.edu> References: <604aa7910507081616458416b5@mail.gmail.com> <200507090619.24545.ermeyers@adelphia.net> <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> Message-ID: <1121364196.13861.50.camel@cutter> > Keeping the tag information in an external file has the converse problem: > every time you want to change (or worse, add) a package, someone has got to > edit the file. And I don't think we want to have a .metadata file for every > package, so it's likely to be Some Central File. > > > About the only reason I can think of for doing it in the spec is > > simplicity > > Exactly. And don't underestimate simplicity. :) Adding a tag or modifying the use of the tag is tricky. yum and rpm are not just fedora things so modifications from here to things have to do with the spec and hence the rpm is tricky. so for simplicity sake - stick with an external file. -sv From ville.skytta at iki.fi Thu Jul 14 18:07:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 21:07:36 +0300 Subject: Review: perl-Crypt-Blowfish / CBC In-Reply-To: References: <1121360332.2872.99.camel@localhost.localdomain> Message-ID: <1121364456.2872.117.camel@localhost.localdomain> On Thu, 2005-07-14 at 19:07 +0200, Andreas Thienemann wrote: > On Thu, 14 Jul 2005, Ville Skytt? wrote: > > > SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-Blowfish/ > > Need to own one more dir, honor $RPM_OPT_FLAGS, non-empty *.bs must not > > be deleted, improve summary and description, trim build deps. See > > patch. > Uhm. Sure about the non-empty stuff? $ man DynaLoader $ less /usr/lib/perl5/5.8.6/i386-linux-thread-multi/DynaLoader.pm $ less /usr/lib/perl5/5.8.6/i386-linux-thread-multi/XSLoader.pm On the other hand, I don't remember seeing a non-empty *.bs. > rpmlint complains about them and on > #fedora-extra I was advised to delete them. That check should be just removed from rpmlint (added to my loooong rpmlint TODO list). It already checks for zero length files, which will catch safely removable *.bs too. From jspaleta at gmail.com Thu Jul 14 18:14:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 14:14:21 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714174508.GA18864@jadzia.bu.edu> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> Message-ID: <604aa791050714111432581eee@mail.gmail.com> On 7/14/05, Matthew Miller wrote: > Yeah; the existing groups could be recogized by the way they contain a "/" > and dealt with as legacy. Or, maybe it wouldn't be considered a tag unless > there's more than one separated by a ",". Or just let 'em be tags that would > generally be ignored. So many possibilities. :) > I could be convinced, but on the contrary, I don't see any pressing need for > it *not* to be, given a better design than the old "GROUPS" list. this is unwieldly and doesn't scale out well to 3rd party repos who need to redefine groups that a package belongs in without having to rebuild any packages. yum groupinstall "Crap for Jef's lan" works because I have a mangled comps.xml file in a local repo and i don't have to rebuild any rpms. Or in a more realistic case a group definition like "Software for Physics 403" sitting in a comps file on a local mirror of a school so all students taking that class can groupinstall all the software for that class in one pass on a fedora system. Some of it from Core or Extras some of it from a local repo. This group definition makes no sense inside an rpm spec because the group is situational for the school for a limited period of time and not something that needs nor should be exposed to all users of all fedora packages. There is no way you can expect the maintainers at build to try to classify all possible structures at build time. But, if we put the editorical information about groupings into easily editted comps files... those comps definitions can be extended or overwritten locally as the situation demands... no need to touch the rpms. Grouping and categorization into components can and will be editorial in nature. Its not unlike playlist creation. On the magical ipod, having my wife and I both create a playlist named "Driving Music" would result in 2 strikingly different sets of songs. tags in songs are mostly informational... playlists are highly personalized and highly situational. Sure having tagging information in the rpms is useful... but its not practical to demand all categorization information exist in rpms.. especially since retagging rpms is not exactly easy to do. For rpms, categorization needs to live outside the packages, so that situational needs can result in new editorial information encoded in comps files as needed. The unedittable group tag just isn't flexible enough to provide a mechanism for dowstream repos to redefine groupings to better serve their local users. -jef From mattdm at mattdm.org Thu Jul 14 18:26:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 14:26:44 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121364196.13861.50.camel@cutter> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <1121364196.13861.50.camel@cutter> Message-ID: <20050714182644.GA20045@jadzia.bu.edu> On Thu, Jul 14, 2005 at 02:03:16PM -0400, seth vidal wrote: > Adding a tag or modifying the use of the tag is tricky. Agreed in general. I don't think that this particular modification would be that far reaching, given that it's mostly not used these days and given that it is an arbitrary-text field. It wouldn't be an rpm-level change, just a spec file creation policy one. Mixing RPMs between distros already doesn't work for a variety of more sigificant reasons. I think the worst case would be that any application which look at "Applications/Internet" and "Applications/Archiving", etc. and construct an "Applications" hierarchy -- when such an app sees "Web Browser; X11; Typical Desktop; Internet Terminal", it's probably going to create a lot of ugly top-level entries. > yum and rpm are not just fedora things so modifications from here to > things have to do with the spec and hence the rpm is tricky. But Fedora RPMs are (basically) Fedora things, yeah? > so for simplicity sake - stick with an external file. How many external files, though? One per repository? One per component? One per rpm (gah!)? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From skvidal at phy.duke.edu Thu Jul 14 18:35:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 14:35:00 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714182644.GA20045@jadzia.bu.edu> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <1121364196.13861.50.camel@cutter> <20050714182644.GA20045@jadzia.bu.edu> Message-ID: <1121366100.13861.61.camel@cutter> On Thu, 2005-07-14 at 14:26 -0400, Matthew Miller wrote: > On Thu, Jul 14, 2005 at 02:03:16PM -0400, seth vidal wrote: > > Adding a tag or modifying the use of the tag is tricky. > > Agreed in general. I don't think that this particular modification would be > that far reaching, given that it's mostly not used these days and given that > it is an arbitrary-text field. It wouldn't be an rpm-level change, just a > spec file creation policy one. Mixing RPMs between distros already doesn't > work for a variety of more sigificant reasons. > > I think the worst case would be that any application which look at > "Applications/Internet" and "Applications/Archiving", etc. and construct an > "Applications" hierarchy -- when such an app sees "Web Browser; X11; Typical > Desktop; Internet Terminal", it's probably going to create a lot of ugly > top-level entries. > > > > yum and rpm are not just fedora things so modifications from here to > > things have to do with the spec and hence the rpm is tricky. > > But Fedora RPMs are (basically) Fedora things, yeah? > > > so for simplicity sake - stick with an external file. > > How many external files, though? One per repository? One per component? One > per rpm (gah!)? one per repository and its contents should be agreed on by the repo maintainer and/or package providers. -sv From andreas at bawue.net Thu Jul 14 18:38:37 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 14 Jul 2005 20:38:37 +0200 (CEST) Subject: Review: perl-Crypt-Blowfish / CBC In-Reply-To: <1121364456.2872.117.camel@localhost.localdomain> References: <1121360332.2872.99.camel@localhost.localdomain> <1121364456.2872.117.camel@localhost.localdomain> Message-ID: On Thu, 14 Jul 2005, Ville Skytt? wrote: > > Uhm. Sure about the non-empty stuff? If you say so. ;-D > > rpmlint complains about them and on > > #fedora-extra I was advised to delete them. > That check should be just removed from rpmlint (added to my loooong > rpmlint TODO list). It already checks for zero length files, which will > catch safely removable *.bs too. Okay, while your on it, please remember to also change the changelog check so it does not complain about the changelog line with the release 1.04 while the package is named 1.04.fc4. bye, andreas From kaboom at oobleck.net Thu Jul 14 18:36:58 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 14:36:58 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714174508.GA18864@jadzia.bu.edu> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> Message-ID: On Thu, 14 Jul 2005, Matthew Miller wrote: > On Thu, Jul 14, 2005 at 01:29:34PM -0400, Chris Ricker wrote: > > > Well, since the current group tag is already Forever More Needed, we might > > > as well reuse it for this. > > If it goes in the spec at all, sure. But is Group abusable to get multiple > > tags? And if you're having to make changes to get Group usable, why not > > just kill it instead? > > You don't have to make changes -- you can put pretty much any arbitrary > string there. Right, but what rpm tools, scripts, etc. out there in the wild that assume they'll never see a "," in Group: will your string with a "," in it break? (or whatever you use as a tag separator. My vote is for "!@&" ;-) Moving from the defined list in GROUPS to anything else, particularly some multi-fielded delimited string, is a change that will likely break something. rpm's the kind of tool that has huge wads of crufty shell scripts and similar built around scraping its output > > retrofitting's needed in the sense of something has to have a tag to be > > categorizable. So if the tag is within the rpm, all the existing rpms > > either need a rebuild (not going to happen, except perhaps for the sphere > > of Fedora) or you have to fall back to the existing meaningless Group tag > > Yeah; the existing groups could be recogized by the way they contain a "/" > and dealt with as legacy. Or, maybe it wouldn't be considered a tag unless > there's more than one separated by a ",". Or just let 'em be tags that would > generally be ignored. So many possibilities. :) See above > > But Some Central File has to change anyway every time packages change, are > > added, etc. That's a solved problem.... > > How so? You mean the yum repo metadata? That's automatically generated from > info in the RPMs themselves.... No, I meant how the whole Fedora infrastructure works makes insertion of tags in Some Central File feasible. For example, right now when you want to request a new build you cd to the cvs co of your rpm and type make build. Behind the scenes that edits Some Central File (common/tobuild in this case) which tracks what needs to be built.... There's no conceptual reason there can't be a common/comps-fe.xml that make rpmtag edits (or whatever -- it just can't be make tag 'cause that's already taken for CVS tagging. My vote would be just for a shared edited file without even fooling with make), and a similar file for the other repositories later, chris From ville.skytta at iki.fi Thu Jul 14 18:47:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 21:47:04 +0300 Subject: Review: perl-Crypt-Blowfish / CBC In-Reply-To: References: <1121360332.2872.99.camel@localhost.localdomain> <1121364456.2872.117.camel@localhost.localdomain> Message-ID: <1121366824.2872.151.camel@localhost.localdomain> On Thu, 2005-07-14 at 20:38 +0200, Andreas Thienemann wrote: > Okay, while your on it, please remember to also change the changelog check > so it does not complain about the changelog line with the release 1.04 > while the package is named 1.04.fc4. Already done in CVS a week ago, will request a build as soon as the buildsys is available again. By the way, I've also fixed some related issues the XEmacs rpm-spec-mode.el; that'll be included in the (real soon now) upcoming xemacs-sumo update. I also pinged Jens, and heard that this fix has been scheduled into the next FC GNU Emacs update, too. (And as some may have noticed, as a result of these fixes, I've actually started to add disttags to some of the packages I maintain :)) From kaboom at oobleck.net Thu Jul 14 18:44:41 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 14 Jul 2005 14:44:41 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa791050714111432581eee@mail.gmail.com> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> <604aa791050714111432581eee@mail.gmail.com> Message-ID: On Thu, 14 Jul 2005, Jeff Spaleta wrote: > yum groupinstall "Crap for Jef's lan" works because I have a mangled > comps.xml file in a local repo and i don't have to rebuild any rpms. > Or in a more realistic case a group definition like "Software for > Physics 403" sitting in a comps file on a local mirror of a school so > all students taking that class can groupinstall all the software for > that class in one pass on a fedora system. Some of it from Core or > Extras some of it from a local repo. This group definition makes no > sense inside an rpm spec because the group is situational for the > school for a limited period of time and not something that needs nor > should be exposed to all users of all fedora packages. There is no > way you can expect the maintainers at build to try to classify all > possible structures at build time. But, if we put the editorical > information about groupings into easily editted comps files... those > comps definitions can be extended or overwritten locally as the > situation demands... no need to touch the rpms. I think Matt is envisioning something a bit different He's saying have basic tags in the rpm (for example, "Web Browser"; "Internet Application"; "X application"; whatever else... for Firefox) Once those tags are in the rpms, still do the grouping stuff outside the rpms via comps or whatever. He's not saying do the actual grouping in the rpms, just the labeling that's used for the external groupings.... To me though, if the grouping stuff has to live outside the rpm "somewhere", the tag might as well live with it "somewhere" as well later, chris From mattdm at mattdm.org Thu Jul 14 18:55:57 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 14:55:57 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa791050714111432581eee@mail.gmail.com> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> <604aa791050714111432581eee@mail.gmail.com> Message-ID: <20050714185557.GB20045@jadzia.bu.edu> On Thu, Jul 14, 2005 at 02:14:21PM -0400, Jeff Spaleta wrote: > this is unwieldly and doesn't scale out well to 3rd party repos who > need to redefine groups that a package belongs in without having to > rebuild any packages. Ideally, the tags/troves would be both general and numerous enough that this wouldn't be a problem. I'm lookin' at it and seeing the *opposite* issue -- every time the repo wants to pull in another little package, they've got this extra step of finding an external file and updating metadata to sync in changes. > yum groupinstall "Crap for Jef's lan" works because I have a mangled > comps.xml file in a local repo and i don't have to rebuild any rpms. This would still work -- you would define "Crap for Jef's lan" as including packages with tags X, Y, and Q. But I see what you're saying. Really, I think this comes down to another difference between the two separate uses for package groupings -- the logical/task-based "Component" type lends itself more to external definition as per comps.xml groups, and the "what kinds of things am I" more to in-spec definitions a la rpm Group. Kind of a shame that both of these use the same word.... And hmmm, so, I guess to my surprise I find myself arguing for making more use of the Group tag after all -- earlier, I'd suggested reducing the accepted values to "Core" and "Extras"..... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. x From mattdm at mattdm.org Thu Jul 14 18:59:07 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 14:59:07 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> Message-ID: <20050714185907.GC20045@jadzia.bu.edu> On Thu, Jul 14, 2005 at 02:36:58PM -0400, Chris Ricker wrote: > There's no conceptual reason there can't be a common/comps-fe.xml that > make rpmtag edits (or whatever -- it just can't be make tag 'cause that's > already taken for CVS tagging. My vote would be just for a shared edited > file without even fooling with make), and a similar file for the other > repositories I guess that sounds okay to me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 14 19:21:39 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Jul 2005 21:21:39 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <1121294582.3432.1.camel@shuttle.273piedmont.com> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> Message-ID: <20050714212139.296a473d@python2> Brian Pepple wrote : > On Wed, 2005-07-13 at 23:15 +0200, Matthias Saou wrote: > > I've packaged gkrellm-bmp and gkrellm-xmms, just to notice that gkrellmms > > was already in Extras (I had done a "yum search gkrellm-*"), and that's > > the plugin I used for both's original name. > > > > This means that although I'd personally prefer to see "gkrellm-xmms" as a > > package, obsoleting "gkrellmms", I'll only be submitting gkrellm-bmp for > > now. > > > > Here it is, ready for review : > > http://ftp.es6.freshrpms.net/tmp/extras/gkrellm-bmp/ > > I currently maintain the package for gkrellmms, but if you have an > interest in taking it over, I'd have no problem. Well, in that case, I'd be interested in hearing your comments regarding the possibility of having a "gkrellm-xmms" package that would obsolete "gkrellmms". You can find such a package next to the "gkrellm-bmp" one. A quick review of both would be much appreciated too ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.12 0.29 0.27 From stickster at gmail.com Thu Jul 14 19:34:07 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 14 Jul 2005 15:34:07 -0400 Subject: No more right click terminal In-Reply-To: <1121355796.3094.18.camel@enki.eridu> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> Message-ID: <1121369647.5118.4.camel@localhost.localdomain> On Thu, 2005-07-14 at 11:43 -0400, Paul Nasrat wrote: > On Wed, 2005-07-13 at 20:17 -0400, Paul W. Frields wrote: > > On Wed, 2005-07-13 at 15:42 -0700, Jesse Keating wrote: > > > On Wed, 2005-07-13 at 13:00 -0400, Colin Walters wrote: > > > > > Someone should just package nautilus-open-terminal, which AFAICS should > > > > address the vast majority of complaints in this thread. > > > > > > If nobody gets to it by the time I"m done w/ my book editing, I'll look > > > at it. > > > I hesitate to speak up in the presence of people far more experienced > > than I, but I did a quick one that anyone is free to criticize, steal, > > and/or adopt. > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > > > Please be gentle, I'm just a doc writer. :-D > > Move to extras list. > > Please keep Paul Frields CC'd in case he hasn't subscribed yet. > > Paul check out the Extras docs here http://fedoraproject.org/wiki/Extras > for how to get this in. Done, requested cvsextras group membership to go with my other existing ones. Paul N., are you willing to check this over? If not, anyone else? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 ermeyers at adelphia.net Thu Jul 14 19:34:22 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Thu, 14 Jul 2005 15:34:22 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507141534.43914.ermeyers@adelphia.net> Gentlemen, Consensus is building. I don't care what the grouping views are called. We just need to agree, and we are. One of the major issues will be clarifying (defuzzying) the groups, and I'll use the group "web-server" as an example. It's a generic name for Typal/Component group. It should be made pure to clarify (defuzzify) its grouping purpose. So packages like 'apachetop' and 'awstats' will need to be moved out into another Typal/Component group called web-server-accessories. As long as we use generic terms for a group, then we'll know that it's a Typal/Component group. The Alphabetical groups will be self explanatory, and anything with an specific name will classify as a Logical/Task group. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Jul 14 19:36:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 15:36:36 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714185557.GB20045@jadzia.bu.edu> References: <20050711042857.GA7425@nostromo.devel.redhat.com> <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> <604aa791050714111432581eee@mail.gmail.com> <20050714185557.GB20045@jadzia.bu.edu> Message-ID: <604aa7910507141236627a4a1f@mail.gmail.com> On 7/14/05, Matthew Miller wrote: > And hmmm, so, I guess to my surprise I find myself arguing for making more > use of the Group tag after all -- earlier, I'd suggested reducing the > accepted values to "Core" and "Extras"..... This is where your head explodes... because as soon as you convince yourself to use the Group tag one way... you'll start arguing to use it the other way when you look at the categorical needs from another prespective. Your change of opinion illustrates another reason why this information needs to be pulled out of the spec tags and into a seperate edittable file(s), so as state-of-the-art opinion changes...the editorial information associated with grouping can occur in parallel with package building.. instead of being bound up in the package building process. With a comps appropriate you can experiment with both component styled groupings and categorical groupings without needing to rebuild packages as categorization schemes evolve. All groupings paradigms are "fuzzy" and more volatile in nature. The rpm header should avoid fuzzy information to avoid problems associated with constantly re-building as new group definitions are defined. Personally I think having multiple alternative comps files is something to look at. One comps file that organizes packages via topic (ie an Editors group). One comps file that organizes via functional components (ie XFCE group) And of course you want to make a hard limit assoicated with the size of any one group definition to make it easy for people producing Fedora Extras mediaset to be able to dump self-consistent groupings onto a single piece of media if at all possible. Having a single group that spans more than a cdrom's worth of data... complicates matters when using mediasets. -jef From jspaleta at gmail.com Thu Jul 14 19:45:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 15:45:09 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141534.43914.ermeyers@adelphia.net> References: <200507141534.43914.ermeyers@adelphia.net> Message-ID: <604aa7910507141245678efa18@mail.gmail.com> On 7/14/05, Eric R. Meyers wrote: > Gentlemen, > > Consensus is building. > > I don't care what the grouping views are called. We just need to agree, and we > are. One of the major issues will be clarifying (defuzzying) the groups, and > I'll use the group "web-server" as an example. It's a generic name for > Typal/Component group. It should be made pure to clarify (defuzzify) its > grouping purpose. So packages like 'apachetop' and 'awstats' will need to be > moved out into another Typal/Component group called web-server-accessories. Uhm.. why exactly do i need a web-server-accessories group? Why can't those packages be optional members of the web server group? If you continue this trend of sub-divding groups so that accessory or optional packages are in their own accessory group... you'll end up with hundreds of visible groups as you subdivide group definitions. This is not a good solution. The comps definition makes room for "optional" packages in a group.. it makes perfect sense to me to place accessories into existing groups and mark them as "optional" so that tools can expose those packages accordingly. -jef From jpo at di.uminho.pt Thu Jul 14 19:45:41 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 14 Jul 2005 20:45:41 +0100 Subject: Review: perl-Crypt-CBC (script files marked as %doc) In-Reply-To: References: <1121360332.2872.99.camel@localhost.localdomain> Message-ID: <42D6C0E5.4000203@di.uminho.pt> Andreas, > >>>SPEC & SRPM: http://home.bawue.net/~ixs/perl-Crypt-CBC/ >> >>Need to own one more dir, and eg/ is referred to in the docs, so it >>would be good to include it. See patch. > > Kay. script files as documentation ----------------------------- When adding script files as documentation it is a good policy to disable their execution permissions. Not disabling them sometimes introduces new requirements. $ rpm -qplv /tmp/rpms/noarch/perl-Crypt-CBC-2.14-1.noarch.rpm ... -rwxr-xr-x ... /usr/share/doc/perl-Crypt-CBC-2.14/eg/aes.pl -rwxr-xr-x ... /usr/share/doc/perl-Crypt-CBC-2.14/eg/des.pl -rwxr-xr-x ... /usr/share/doc/perl-Crypt-CBC-2.14/eg/idea.pl ... $ rpm -qpR /tmp/rpms/noarch/perl-Crypt-CBC-2.14-1.noarch.rpm ... perl(Crypt::CBC) perl(Crypt::IDEA) perl(Digest::MD5) .... In particular, the package perl-Crypt-IDEA doesn't exists in Core/Extras. Solution: Just add the following line (or something similar) to %prep section: chmod 644 eg/*.pl Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Jul 14 19:48:45 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 15:48:45 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141534.43914.ermeyers@adelphia.net> References: <200507141534.43914.ermeyers@adelphia.net> Message-ID: <20050714194845.GA23742@jadzia.bu.edu> On Thu, Jul 14, 2005 at 03:34:22PM -0400, Eric R. Meyers wrote: > I don't care what the grouping views are called. We just need to agree, > and we are. One of the major issues will be clarifying (defuzzying) the > groups, and I'll use the group "web-server" as an example. It's a generic > name for Typal/Component group. It should be made pure to clarify > (defuzzify) its grouping purpose. So packages like 'apachetop' and > 'awstats' will need to be moved out into another Typal/Component group > called web-server-accessories. As long as we use generic terms for a > group, then we'll know that it's a Typal/Component group. The Alphabetical > groups will be self explanatory, and anything with an specific name will > classify as a Logical/Task group. Just to clarify -- I think Component is a better name for Logical/Task groups, not for the "Typal" groups (which maybe, following Freshmeat, could be called "Troves"). A "Web Server" component/logical/task group could be something like the existing one, containing httpd, httpd-suexec, mod_*, php-*, webalizer, etc. Then, a package like httpd would also be in various typal/trove groups: Daemon, HTTP server, Internet Server. The package webalizer would be in Console, Log Analizer, Web Tool. (Or something like that.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From ville.skytta at iki.fi Thu Jul 14 19:50:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Jul 2005 22:50:04 +0300 Subject: Review: perl-Crypt-CBC (script files marked as %doc) In-Reply-To: <42D6C0E5.4000203@di.uminho.pt> References: <1121360332.2872.99.camel@localhost.localdomain> <42D6C0E5.4000203@di.uminho.pt> Message-ID: <1121370604.2872.179.camel@localhost.localdomain> On Thu, 2005-07-14 at 20:45 +0100, Jos? Pedro Oliveira wrote: > Solution: > Just add the following line (or something similar) to %prep section: > > chmod 644 eg/*.pl Doh! I could've sworn I checked they're not executable. My bad, thanks for the catch, Jose! From mattdm at mattdm.org Thu Jul 14 19:51:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 15:51:55 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507141236627a4a1f@mail.gmail.com> References: <20050714141258.GA9982@jadzia.bu.edu> <20050714161146.GA14554@jadzia.bu.edu> <20050714172310.GA17720@jadzia.bu.edu> <20050714174508.GA18864@jadzia.bu.edu> <604aa791050714111432581eee@mail.gmail.com> <20050714185557.GB20045@jadzia.bu.edu> <604aa7910507141236627a4a1f@mail.gmail.com> Message-ID: <20050714195155.GB23742@jadzia.bu.edu> On Thu, Jul 14, 2005 at 03:36:36PM -0400, Jeff Spaleta wrote: > This is where your head explodes... because as soon as you convince Okay, fine. :) Then, dammit, let's set the Group tag to "Extras" for all Fedora Extras packages. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From jspaleta at gmail.com Thu Jul 14 19:54:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 15:54:33 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714194845.GA23742@jadzia.bu.edu> References: <200507141534.43914.ermeyers@adelphia.net> <20050714194845.GA23742@jadzia.bu.edu> Message-ID: <604aa7910507141254253a4240@mail.gmail.com> On 7/14/05, Matthew Miller wrote: > Then, a package like httpd would also be in various typal/trove groups: > Daemon, HTTP server, Internet Server. The package webalizer would be in > Console, Log Analizer, Web Tool. (Or something like that.) A flat display of ALL such trove items isnt going to work from a ui perspective. following the freshmeat model... the trove is nested.. with at most about a page worth of sub-categories at each nesting level. Unless there is a commitment to build tools with ui that can deal sanely with nesting groups the freshmeat trove model breaks down. Having 200 hundred trove-like groups in a flat list is not a good idea. -jef From jpo at di.uminho.pt Thu Jul 14 20:01:37 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Thu, 14 Jul 2005 21:01:37 +0100 Subject: Review: perl-Crypt-CBC (script files marked as %doc) In-Reply-To: <1121370604.2872.179.camel@localhost.localdomain> References: <1121360332.2872.99.camel@localhost.localdomain> <42D6C0E5.4000203@di.uminho.pt> <1121370604.2872.179.camel@localhost.localdomain> Message-ID: <42D6C4A1.8090004@di.uminho.pt> Ville Skytt? wrote: > On Thu, 2005-07-14 at 20:45 +0100, Jos? Pedro Oliveira wrote: > > >>Solution: >>Just add the following line (or something similar) to %prep section: >> >> chmod 644 eg/*.pl > > > Doh! I could've sworn I checked they're not executable. My bad, thanks > for the catch, Jose! I have packaged several Crypt::* modules in the past. This was one of them ;) jpo PS - Some perl-Crypt-* SRPMS are available here http://gsd.di.uminho.pt/jpo/perl/SRPMS/ in case someone wants to take a look at them. The specfiles need to be updated as they were packaged a year ago using the fedora.us template. -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Jul 14 20:14:24 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Jul 2005 16:14:24 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507141254253a4240@mail.gmail.com> References: <200507141534.43914.ermeyers@adelphia.net> <20050714194845.GA23742@jadzia.bu.edu> <604aa7910507141254253a4240@mail.gmail.com> Message-ID: <20050714201424.GA24774@jadzia.bu.edu> On Thu, Jul 14, 2005 at 03:54:33PM -0400, Jeff Spaleta wrote: > A flat display of ALL such trove items isnt going to work from a ui > perspective. following the freshmeat model... the trove is nested.. > with at most about a page worth of sub-categories at each nesting > level. Unless there is a commitment to build tools with ui that can > deal sanely with nesting groups the freshmeat trove model breaks down. > Having 200 hundred trove-like groups in a flat list is not a good > idea. No, it's not. :) But I don't think the hierarchy should be defined in the tags themselves, or else we're back to the same old Groups problem. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From pnasrat at redhat.com Thu Jul 14 20:26:52 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 14 Jul 2005 16:26:52 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121369647.5118.4.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> Message-ID: <1121372812.3523.15.camel@enki.eridu> > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > > > > Done, requested cvsextras group membership to go with my other existing > ones. Paul N., are you willing to check this over? If not, anyone > else? Review based on http://fedoraproject.org/wiki/PackagingGuidelines it's been a while since I did QA. Source against upstream and independant download: http://manny.cluecoder.org/packages/nautilus-open-terminal/nautilus-open-terminal-0.4.tar.gz.md5 md5 931a50e602f60340a5ed369f50146f36 nautilus-open-terminal-0.4.tar.gz Source License is GPL, no known legal issues. Builds locally using rpmbuild and mock - so buildrequires form all requirements. Terminal menu appears after logout/login and using nautilus -q (tested both mock built and system built package) However: rpmlint gives: W: nautilus-open-terminal devel-file-in-non-devel-package /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.a E: nautilus-open-terminal script-without-shellbang /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.la Indeed - you probably just want to nuke the .a and .la files Paul From stickster at gmail.com Thu Jul 14 21:30:08 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 14 Jul 2005 17:30:08 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121372812.3523.15.camel@enki.eridu> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> Message-ID: <1121376609.2975.3.camel@localhost.localdomain> On Thu, 2005-07-14 at 16:26 -0400, Paul Nasrat wrote: > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > > > Done, requested cvsextras group membership to go with my other existing > > ones. Paul N., are you willing to check this over? If not, anyone > > else? > > Review based on http://fedoraproject.org/wiki/PackagingGuidelines it's > been a while since I did QA. > > Source against upstream and independant download: > > http://manny.cluecoder.org/packages/nautilus-open-terminal/nautilus-open-terminal-0.4.tar.gz.md5 > md5 931a50e602f60340a5ed369f50146f36 nautilus-open-terminal-0.4.tar.gz > > Source License is GPL, no known legal issues. > > Builds locally using rpmbuild and mock - so buildrequires form all > requirements. > > Terminal menu appears after logout/login and using nautilus -q (tested > both mock built and system built package) > > However: > > rpmlint gives: > W: nautilus-open-terminal devel-file-in-non-devel-package /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.a > E: nautilus-open-terminal > script-without-shellbang /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.la > > Indeed - you probably just want to nuke the .a and .la files Done. See 0.4-3 at same location. Sorry I missed the section on rpmlint; everyone has to start somewhere, I suppose. I'll be sure to use it in the future (and reread spot's Guidelines). -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 jspaleta at gmail.com Thu Jul 14 22:08:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 18:08:03 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050714201424.GA24774@jadzia.bu.edu> References: <200507141534.43914.ermeyers@adelphia.net> <20050714194845.GA23742@jadzia.bu.edu> <604aa7910507141254253a4240@mail.gmail.com> <20050714201424.GA24774@jadzia.bu.edu> Message-ID: <604aa791050714150831ea6fda@mail.gmail.com> On 7/14/05, Matthew Miller wrote: > No, it's not. :) But I don't think the hierarchy should be defined in the > tags themselves, or else we're back to the same old Groups problem. its not exactly the same problem.. I dont have to rebuild 1400 packages to re-order or re-nest groups defined in a comps file. I just have to edit that one comps file. That is a BIG difference. -jef From ermeyers at adelphia.net Fri Jul 15 01:37:04 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Thu, 14 Jul 2005 21:37:04 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507142137.18869.ermeyers@adelphia.net> To whom it may concern, I downloaded: http://fedoraproject.org/extras/ http://fedoraproject.org/extras/4/ http://fedoraproject.org/extras/4/386/ http://fedoraproject.org/extras/4/386/repodata/ http://fedoraproject.org/extras/4/386/repodata/repoview Just to get a better repoview. : ) Repoview's current tally of 1271 packages is incorrect. The actual count should be 1107. Run this perl script in http://fedoraproject.org/extras/4/386/ directory, and it will point you to the files that have multiple versions stored there. When it doesn't output anything you're done. ---------------------- findrepeats.plx: ---------------------- #!/usr/bin/perl -w ## opendir( DH, '.' ) || die; @rpmfile = grep { /\.(i[3]86|noarch)\.rpm$/ } readdir( DH ); closedir( DH ); %seen = (); foreach $x ( @rpmfile ) { $x =~ s/\r?\n//; $x =~ m/^(.+)-([^-]+-.+)[.](i[3]86|noarch)[.]rpm$/; ##debug##printf( "%-30s %s\n", $1, $2 ); if ( ! defined( $seen{$1} ) ) { $seen{$1} = 1; } else { printf( "%s\n", $1 ); } ## end if } ## end foreach Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazquez at ivazquez.net Fri Jul 15 01:48:37 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Jul 2005 21:48:37 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507142137.18869.ermeyers@adelphia.net> References: <200507142137.18869.ermeyers@adelphia.net> Message-ID: <1121392117.6290.22.camel@ignacio.lan> On Thu, 2005-07-14 at 21:37 -0400, Eric R. Meyers wrote: > Run this perl script in http://fedoraproject.org/extras/4/386/ directory, and > it will point you to the files that have multiple versions stored there. > When it doesn't output anything you're done. Or you can just use repomanage that comes in the yum-utils package. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mfleming at enlartenment.com Fri Jul 15 01:47:36 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Fri, 15 Jul 2005 11:47:36 +1000 Subject: Request for review / approval: mod_security. In-Reply-To: <42D374E0.8090508@linux-kernel.at> References: <20050709212706.0e6bdb21.mfleming@enlartenment.com> <200507092119.j69LJlrP014361@mail.linux-kernel.at> <20050711234301.GA4689@enlartenment.com> <42D374E0.8090508@linux-kernel.at> Message-ID: <20050715014736.GA2502@enlartenment.com> On Tue, Jul 12, 2005 at 09:44:32AM +0200, Oliver Falk waffled thusly: > On 07/12/2005 01:43 AM, Michael Fleming wrote: [Oliver] > >Any more comments on this? Perhaps any interesting or useful rules for > >common apps I'm not aware of (I think I've covered the usual suspects). > >Official approval for a build and cvssync perhaps? ;-) > > None for my side. Commit it, check the owners.list, check Bugzilla, > check if you need any more branches, wait 'til the new buildsys is ready > to use and fire a build request :-) All done bar the cvssync (I'll sort out this one via the relevant wiki page) and build - if this is considered approved shall I send the APPROVED message to -commits or should I leave it with you (or perhaps another reviewer if they wish)? I'm confident any build will be fine (it WORKSFORME), I'm just following the set procedure. :-D > Best, > Oliver Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From skvidal at phy.duke.edu Fri Jul 15 06:17:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 15 Jul 2005 02:17:29 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507142137.18869.ermeyers@adelphia.net> References: <200507142137.18869.ermeyers@adelphia.net> Message-ID: <1121408249.22260.36.camel@cutter> On Thu, 2005-07-14 at 21:37 -0400, Eric R. Meyers wrote: > To whom it may concern, > > I downloaded: > http://fedoraproject.org/extras/ > http://fedoraproject.org/extras/4/ > http://fedoraproject.org/extras/4/386/ > http://fedoraproject.org/extras/4/386/repodata/ > http://fedoraproject.org/extras/4/386/repodata/repoview > > Just to get a better repoview. : ) > > Repoview's current tally of 1271 packages is incorrect. The actual count > should be 1107. the repository metadata count shows as 1271 - which is where repoview gets the numbers from. If you take a complete list of pkgs from the repo and remove out the debuginfo and src.rpms you end up with 1271 individual packages. > Run this perl script in http://fedoraproject.org/extras/4/386/ directory, and > it will point you to the files that have multiple versions stored there. > When it doesn't output anything you're done. why on earth would you do anything in perl :) yum install yum-utils repomanage -o /some/path that will list all the old packages in the repository that could be removed. -sv From symbiont at berlios.de Fri Jul 15 06:41:37 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 15 Jul 2005 14:41:37 +0800 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050714124843.1c9034a6.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D6105C.4000204@linux-kernel.at> <20050714124843.1c9034a6.bugs.michael@gmx.net> Message-ID: <200507151441.37542.symbiont@berlios.de> On Thursday 14 July 2005 18:48, Michael Schwendt wrote: > Mandatory dist tags give a false impression of upgrade-path safety. *shrug* If they don't need disttags, that means they can move over across a dist upgrade which gives a false impression of upgrade-path safety. In fact, the rest of your points can be readily applied to packages that don't need disttags, but float across dist upgrades. In other words, we're going in circles when it's really unnecessary. If we're just saving a rebuild by dropping a %{?dist}, I don't really see that as a huge plus. Cause, I don't think CPUs will be going on strike any time soon. -- -jeff From pmatilai at laiskiainen.org Fri Jul 15 07:06:44 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 15 Jul 2005 10:06:44 +0300 Subject: wine for fedora core 4? In-Reply-To: <42D679BF.80608@linux-kernel.at> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> Message-ID: <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> On Thu, 2005-07-14 at 16:42 +0200, Oliver Falk wrote: > On 07/14/2005 04:22 PM, Jan Scott wrote: > > I use fedora core 4 and want to install wine. But there are only rpm's > > available for fedora core 1 , 2 , 3. > > Is it safe to use the rpm corresponding with fedora core 3? > > Strange this is, there is an empty wine dir in extras devel repo: > > [oliver at moon extras] ls wine/ > CVS > > But for branch FC-3, RHL-9, there are the files (just checked 'em out) > and owners.list tells me, who is the owner: > > [oliver at moon owners]$ grep wine owners.list > Fedora Extras|wine|A Windows 16/32 bit emulator|pmatilai at laiskiainen.org > > So it seems, the branch was made, but the files never copied and so no > build was requested yet... Once upon a time I maintained a wine package for fedora.us but had to drop it due to lack of time for wrestling with the beast as when I no longer had any personal interest in it. It just got imported into FE CVS in the mass import from fedora.us repositories, it's never been built for FE however. - Panu - From oliver at linux-kernel.at Fri Jul 15 07:10:53 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:10:53 +0200 Subject: wine for fedora core 4? In-Reply-To: <20050714184529.4e809498.bugs.michael@gmx.net> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> <20050714184529.4e809498.bugs.michael@gmx.net> Message-ID: <42D7617D.5010304@linux-kernel.at> On 07/14/2005 06:45 PM, Michael Schwendt wrote: > On Thu, 14 Jul 2005 16:42:07 +0200, Oliver Falk wrote: > > >>On 07/14/2005 04:22 PM, Jan Scott wrote: >> >>>I use fedora core 4 and want to install wine. But there are only rpm's >>>available for fedora core 1 , 2 , 3. >>>Is it safe to use the rpm corresponding with fedora core 3? >> >>Strange this is, there is an empty wine dir in extras devel repo: >> >>[oliver at moon extras] ls wine/ >>CVS >> >>But for branch FC-3, RHL-9, there are the files (just checked 'em out) >>and owners.list tells me, who is the owner: >> >>[oliver at moon owners]$ grep wine owners.list >>Fedora Extras|wine|A Windows 16/32 bit emulator|pmatilai at laiskiainen.org >> >>So it seems, the branch was made, but the files never copied and so no >>build was requested yet... > > > "devel" is not a branch, FC-4, FC-3 and older are. If a package is > discontinued, the first place where to delete the files is "devel". > "devel" only contained wine because devel is where a module is started > before it's branched. The version of wine that was imported is from rh9 > times and was branched by accident. Have a look at "cvs log". Yes, devel is not a branch, you are correct - of course. And you are correct, I should have watched the cvs log... :-) Best, Oliver From oliver at linux-kernel.at Fri Jul 15 07:20:26 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:20:26 +0200 Subject: Request for review / approval: mod_security. In-Reply-To: <20050715014736.GA2502@enlartenment.com> References: <20050709212706.0e6bdb21.mfleming@enlartenment.com> <200507092119.j69LJlrP014361@mail.linux-kernel.at> <20050711234301.GA4689@enlartenment.com> <42D374E0.8090508@linux-kernel.at> <20050715014736.GA2502@enlartenment.com> Message-ID: <42D763BA.1020401@linux-kernel.at> On 07/15/2005 03:47 AM, Michael Fleming wrote: > On Tue, Jul 12, 2005 at 09:44:32AM +0200, Oliver Falk waffled thusly: > >>On 07/12/2005 01:43 AM, Michael Fleming wrote: > > > > > [Oliver] > >>>Any more comments on this? Perhaps any interesting or useful rules for >>>common apps I'm not aware of (I think I've covered the usual suspects). >>>Official approval for a build and cvssync perhaps? ;-) >> >>None for my side. Commit it, check the owners.list, check Bugzilla, >>check if you need any more branches, wait 'til the new buildsys is ready >>to use and fire a build request :-) > > > All done bar the cvssync (I'll sort out this one via the relevant wiki > page) and build - if this is considered approved shall I send the > APPROVED message to -commits or should I leave it with you (or perhaps > another reviewer if they wish)? > > I'm confident any build will be fine (it WORKSFORME), I'm just following > the set procedure. :-D I just sent out the approval. So feel free to build it :-) Best, Oliver From oliver at linux-kernel.at Fri Jul 15 07:22:23 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:22:23 +0200 Subject: [Fwd: Request for review: libdnet] In-Reply-To: <42D6CC8F.9060408@di.uminho.pt> References: <42CE7705.2090002@linux-kernel.at> <42D544E6.4010503@di.uminho.pt> <42D615E7.8080705@linux-kernel.at> <42D6CC8F.9060408@di.uminho.pt> Message-ID: <42D7642F.4090601@linux-kernel.at> Hi Jos?! On 07/14/2005 10:35 PM, Jos? Pedro Oliveira wrote: >>Please review again/approve, new release (2) has just been uploaded: >>http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet/ > > Everything looks good. I will send the approval email > in a couple of hours (after testing it with scanssh). :-) That's exactly why I want this in Extras, I have a scanssh package as well, that I want to include. With my scanssh it works. Thanks for review, let me know (send out approval) if I can cvs-import it. Merci, Oliver From oliver at linux-kernel.at Fri Jul 15 07:24:28 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:24:28 +0200 Subject: wine for fedora core 4? In-Reply-To: <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> Message-ID: <42D764AC.6030701@linux-kernel.at> On 07/15/2005 09:06 AM, Panu Matilainen wrote: > On Thu, 2005-07-14 at 16:42 +0200, Oliver Falk wrote: > >>On 07/14/2005 04:22 PM, Jan Scott wrote: >> >>>I use fedora core 4 and want to install wine. But there are only rpm's >>>available for fedora core 1 , 2 , 3. >>>Is it safe to use the rpm corresponding with fedora core 3? >> >>Strange this is, there is an empty wine dir in extras devel repo: >> >>[oliver at moon extras] ls wine/ >>CVS >> >>But for branch FC-3, RHL-9, there are the files (just checked 'em out) >>and owners.list tells me, who is the owner: >> >>[oliver at moon owners]$ grep wine owners.list >>Fedora Extras|wine|A Windows 16/32 bit emulator|pmatilai at laiskiainen.org >> >>So it seems, the branch was made, but the files never copied and so no >>build was requested yet... > > > Once upon a time I maintained a wine package for fedora.us but had to > drop it due to lack of time for wrestling with the beast as when I no > longer had any personal interest in it. It just got imported into FE CVS > in the mass import from fedora.us repositories, it's never been built > for FE however. OK, this means, it's a official 'ask for a new packager'? :-) Best, Oliver From oliver at linux-kernel.at Fri Jul 15 07:31:28 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:31:28 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <200507151441.37542.symbiont@berlios.de> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D6105C.4000204@linux-kernel.at> <20050714124843.1c9034a6.bugs.michael@gmx.net> <200507151441.37542.symbiont@berlios.de> Message-ID: <42D76650.1070605@linux-kernel.at> On 07/15/2005 08:41 AM, Jeff Pitman wrote: > On Thursday 14 July 2005 18:48, Michael Schwendt wrote: > >>Mandatory dist tags give a false impression of upgrade-path safety. > > *shrug* > > If they don't need disttags, that means they can move over across a dist > upgrade which gives a false impression of upgrade-path safety. > > In fact, the rest of your points can be readily applied to packages that > don't need disttags, but float across dist upgrades. > > In other words, we're going in circles when it's really unnecessary. > > If we're just saving a rebuild by dropping a %{?dist}, I don't really > see that as a huge plus. Cause, I don't think CPUs will be going on > strike any time soon. Copy that - with a :-) Let's say, if it's really some (eg game) data, that is not actually *build*, but only copied to some place, with may makes no sense to add a dist tag, but I believe in most cases we will need the dist tag. However, there *are* cases where the dist tag really is not necessary and in those cases I would not recommend. That's *my* point, OK? Best, Oliver From pmatilai at laiskiainen.org Fri Jul 15 07:35:00 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 15 Jul 2005 10:35:00 +0300 Subject: wine for fedora core 4? In-Reply-To: <42D764AC.6030701@linux-kernel.at> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> <42D764AC.6030701@linux-kernel.at> Message-ID: <1121412900.25163.8.camel@weasel.turre.laiskiainen.org> On Fri, 2005-07-15 at 09:24 +0200, Oliver Falk wrote: > On 07/15/2005 09:06 AM, Panu Matilainen wrote: > > > > > > Once upon a time I maintained a wine package for fedora.us but had to > > drop it due to lack of time for wrestling with the beast as when I no > > longer had any personal interest in it. It just got imported into FE CVS > > in the mass import from fedora.us repositories, it's never been built > > for FE however. > > OK, this means, it's a official 'ask for a new packager'? :-) Yes :) Back then, I asked around couple of times but nobody was interested enough to take over maintainership. Even talked to the people creating the upstream rpm's but they had.. um, issues, with the fedora.us process. Things being very different with FE, they just *might* be more interested... - Panu - From oliver at linux-kernel.at Fri Jul 15 07:46:16 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:46:16 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121291752.1574.393.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> Message-ID: <42D769C8.8070808@linux-kernel.at> Hi Alexander! On 07/13/2005 11:55 PM, Alexander Dalloz wrote: > Am Mo, den 11.07.2005 schrieb Alexander Dalloz um 18:42: > Its me again - next round for a review :) > > http://www.uni-x.org/pam_abl-0.2.2-1.src.rpm > http://www.uni-x.org/pam_abl.spec > > Beside changes to be found in %changelog some additional notes: > > - the author of pam_abl Andy Armstrong replied very quickly and friendly > to my mail: future versions will no longer have the date string in the > tarball's name; releases are only differed by the release number > (current on is 0.2.2) Great! > so I changed the release tag, being aware that this would mean a lower > value now than before; think it does no harm here as the package is > still in review and the former one histore now Yes, that's OK - at least for me. > - running rpmlint gives me: > $ rpmlint pam_abl-0.2.2-1.i386.rpm > E: pam_abl library-not-linked-against-libc /lib/security/pam_abl.so > I am confused as of: > $ ldd /lib/security/pam_abl.so > libdb-4.2.so => /lib/tls/libdb-4.2.so (0x00a9e000) > libpthread.so.0 => /lib/tls/libpthread.so.0 (0x003d7000) > libc.so.6 => /lib/tls/libc.so.6 (0x00111000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x008fd000) I don't get this: [of at moon SPECS]$ rpmlint ../SRPMS/pam_abl-0.2.2-1.src.rpm [of at moon SPECS]$ > - Oliver, rereading your first review I noticed that you commented about > the .spec file: > * You should not make > Could you please tell me what is meant by that? I cannot remember, but I took a second look at the spec, see notes below. > Further critics appreciated, but would be glad too to hear this is a > major step forward to being approved. Yes, it's a major step forward :-) Attached is a patch with recommended changes. You don't have to apply all the whitespace stuff I added, it was just some cosmetic... But: * Macro usage was inconsitant * At some points macros weren't used (eg. _sysconfdir} * Added a fine for the reldate (even if it will not live very long) * Moved pam_abl from /sbin to /usr/sbin - you don't need this before a possible external /usr gets mounted. Best, Oliver -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pam_abl.recom.spec URL: From oliver at linux-kernel.at Fri Jul 15 07:50:36 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 09:50:36 +0200 Subject: wine for fedora core 4? In-Reply-To: <1121412900.25163.8.camel@weasel.turre.laiskiainen.org> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> <42D764AC.6030701@linux-kernel.at> <1121412900.25163.8.camel@weasel.turre.laiskiainen.org> Message-ID: <42D76ACC.9040405@linux-kernel.at> On 07/15/2005 09:35 AM, Panu Matilainen wrote: > On Fri, 2005-07-15 at 09:24 +0200, Oliver Falk wrote: > >>On 07/15/2005 09:06 AM, Panu Matilainen wrote: >> >>> >>>Once upon a time I maintained a wine package for fedora.us but had to >>>drop it due to lack of time for wrestling with the beast as when I no >>>longer had any personal interest in it. It just got imported into FE CVS >>>in the mass import from fedora.us repositories, it's never been built >>>for FE however. >> >>OK, this means, it's a official 'ask for a new packager'? :-) > > > Yes :) Folks, did you hear that? Just to let you know, *I'm* not interessted, as I don't use wine - the software... :-) > Back then, I asked around couple of times but nobody was interested > enough to take over maintainership. Even talked to the people creating > the upstream rpm's but they had.. um, issues, with the fedora.us > process. Things being very different with FE, they just *might* be more > interested... OK, so give 'em a new chance. Maybe someone want's to do it now... I believe it's a good piece of software, isn't it? Best, Oliver From bugs.michael at gmx.net Fri Jul 15 08:32:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 15 Jul 2005 10:32:35 +0200 Subject: %{?dist} (was: Re: Request for a sponsor and a review of: pam_abl) In-Reply-To: <200507151441.37542.symbiont@berlios.de> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D6105C.4000204@linux-kernel.at> <20050714124843.1c9034a6.bugs.michael@gmx.net> <200507151441.37542.symbiont@berlios.de> Message-ID: <20050715103235.7f9dc6ed.bugs.michael@gmx.net> On Fri, 15 Jul 2005 14:41:37 +0800, Jeff Pitman wrote: > On Thursday 14 July 2005 18:48, Michael Schwendt wrote: > > Mandatory dist tags give a false impression of upgrade-path safety. > > *shrug* > > If they don't need disttags, that means they can move over across a dist > upgrade which gives a false impression of upgrade-path safety. To allow for CD based installations/upgrades, a version jump for a distribution upgrade would normally look like this, FC2: foo-1.0-1, Update: foo-1.0-1.2, foo-1.0-1.3 FC3: foo-1.0-2, Update: foo-1.0-3 FC4: foo-1.0-4 or similar, but with all version-release tuples for an older dist being older than all version-release tuples for all newer dists. This scheme is not aided by dist tags. Btw, you've still not given a good reason why you want to enforce %{?dist} on packagers. Where is the value in making it mandatory? From tmraz at redhat.com Fri Jul 15 09:14:09 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 15 Jul 2005 11:14:09 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D769C8.8070808@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> Message-ID: <1121418849.5311.6.camel@perun.redhat.usu> On Fri, 2005-07-15 at 09:46 +0200, Oliver Falk wrote: > 31,33c38,40 > < install -D -m 644 conf/pam_abl.conf %{buildroot}/etc/security/pam_abl.conf > < install -D -m 755 tools/pam_abl %{buildroot}/sbin/pam_abl > < install -d -m 755 %{buildroot}%{_localstatedir}/lib/abl > --- > > install -D -m 644 conf/pam_abl.conf %{buildroot}/%{_sysconfdir}/security/pam_abl.conf > > install -D -m 755 tools/pam_abl %{buildroot}/%{_sbindir}/pam_abl > > install -d -m 755 %{buildroot}%{_localstatedir}/%{_lib}/abl %{_sysconfdir} and %{_sbindir} begin with / already And moreover the pam_abl binary should be probably installed in /sbin and not /usr/sbin as you suggest by using %{_sbindir}. %{_lib} after _localstatedir is wrong - it expands to lib64 on 64bit arches. > 44c51 > < %config(noreplace) /etc/security/pam_abl.conf > --- > > %config(noreplace) /%{_sysconfdir}/security/pam_abl.conf The same as above. > 46,47c53,54 > < /sbin/pam_abl > < %{_localstatedir}/lib/abl/ > --- > > %{_sbindir}/pam_abl > > %{_localstatedir}/%{_lib}/abl/ Again. -- Tomas Mraz From oliver at linux-kernel.at Fri Jul 15 09:24:39 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 11:24:39 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121418849.5311.6.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121418849.5311.6.camel@perun.redhat.usu> Message-ID: <42D780D7.1040308@linux-kernel.at> On 07/15/2005 11:14 AM, Tomas Mraz wrote: > On Fri, 2005-07-15 at 09:46 +0200, Oliver Falk wrote: > >>31,33c38,40 >>< install -D -m 644 conf/pam_abl.conf %{buildroot}/etc/security/pam_abl.conf >>< install -D -m 755 tools/pam_abl %{buildroot}/sbin/pam_abl >>< install -d -m 755 %{buildroot}%{_localstatedir}/lib/abl >>--- >> >>>install -D -m 644 conf/pam_abl.conf %{buildroot}/%{_sysconfdir}/security/pam_abl.conf >>>install -D -m 755 tools/pam_abl %{buildroot}/%{_sbindir}/pam_abl >>>install -d -m 755 %{buildroot}%{_localstatedir}/%{_lib}/abl > > %{_sysconfdir} and %{_sbindir} begin with / already Yes, correct. The / should be removed. > And moreover the pam_abl binary should be probably installed in /sbin > and not /usr/sbin as you suggest by using %{_sbindir}. Any *good* reason for installing it in /sbin, rather than /usr/sbin? > %{_lib} after _localstatedir is wrong - it expands to lib64 on 64bit > arches. Oops, yes, substitute problem. >>44c51 >>< %config(noreplace) /etc/security/pam_abl.conf >>--- >> >>>%config(noreplace) /%{_sysconfdir}/security/pam_abl.conf > > The same as above. Yes, the slash should be removed. >>46,47c53,54 >>< /sbin/pam_abl >>< %{_localstatedir}/lib/abl/ >>--- >> >>>%{_sbindir}/pam_abl >>>%{_localstatedir}/%{_lib}/abl/ OK. Attached is the (slash-)corrected patch for Alexander. Best, Oliver -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pam_abl.recom.spec URL: From tmraz at redhat.com Fri Jul 15 09:33:16 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 15 Jul 2005 11:33:16 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D780D7.1040308@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121418849.5311.6.camel@perun.redhat.usu> <42D780D7.1040308@linux-kernel.at> Message-ID: <1121419996.5311.9.camel@perun.redhat.usu> On Fri, 2005-07-15 at 11:24 +0200, Oliver Falk wrote: > On 07/15/2005 11:14 AM, Tomas Mraz wrote: > > And moreover the pam_abl binary should be probably installed in /sbin > > and not /usr/sbin as you suggest by using %{_sbindir}. > > Any *good* reason for installing it in /sbin, rather than /usr/sbin? For consistency with other pam utilities? Such as pam_tally, pam_timestamp_check, pam_console_apply. -- Tomas Mraz From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 15 09:51:21 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 15 Jul 2005 11:51:21 +0200 Subject: wine for fedora core 4? In-Reply-To: <42D76ACC.9040405@linux-kernel.at> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> <42D764AC.6030701@linux-kernel.at> <1121412900.25163.8.camel@weasel.turre.laiskiainen.org> <42D76ACC.9040405@linux-kernel.at> Message-ID: <20050715115121.47cfd92e@python2> Oliver Falk wrote : > Just to let you know, *I'm* not interessted, as I don't use wine - the > software... :-) Anyone the least bit interested could contact Rudolf Kastl, and either work with him to have him import and maintain his wine package in Extras, or to cooperate and proxy his changes to Extras. http://newrpms.sunsite.dk/ It would definitely be a good idea since he works closely with the upstream wine developers for his packages, tests regressions etc. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.41 0.82 0.89 From oliver at linux-kernel.at Fri Jul 15 11:18:07 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 13:18:07 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121419996.5311.9.camel@perun.redhat.usu> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121418849.5311.6.camel@perun.redhat.usu> <42D780D7.1040308@linux-kernel.at> <1121419996.5311.9.camel@perun.redhat.usu> Message-ID: <42D79B6F.7020109@linux-kernel.at> On 07/15/2005 11:33 AM, Tomas Mraz wrote: > On Fri, 2005-07-15 at 11:24 +0200, Oliver Falk wrote: > >>On 07/15/2005 11:14 AM, Tomas Mraz wrote: >> >>>And moreover the pam_abl binary should be probably installed in /sbin >>>and not /usr/sbin as you suggest by using %{_sbindir}. >> >>Any *good* reason for installing it in /sbin, rather than /usr/sbin? > > For consistency with other pam utilities? Such as pam_tally, > pam_timestamp_check, pam_console_apply. rpm -qpl pam_krb5 | grep bin /usr/bin/afs5log rpm -qpl pam_mount | grep bin /usr/bin/autoehd /usr/bin/mkehd /usr/bin/mount.crypt /usr/bin/mount_ehd /usr/bin/passwdehd /usr/bin/umount.crypt /usr/sbin/pmvarrun So normally, all pam_* binaries, that don't belong to the base pam package, are not install ind /bin or /sbin. Also the pam_abl binary is not needed at boot-time, where a possible nfs-mounted /usr partion get's mounted, so no need to put it in /sbin... But it's a cosmetic/design decision, isn't it? :-) Best, Oliver From tmraz at redhat.com Fri Jul 15 11:34:13 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 15 Jul 2005 13:34:13 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D79B6F.7020109@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121418849.5311.6.camel@perun.redhat.usu> <42D780D7.1040308@linux-kernel.at> <1121419996.5311.9.camel@perun.redhat.usu> <42D79B6F.7020109@linux-kernel.at> Message-ID: <1121427253.5311.14.camel@perun.redhat.usu> On Fri, 2005-07-15 at 13:18 +0200, Oliver Falk wrote: > On 07/15/2005 11:33 AM, Tomas Mraz wrote: > > On Fri, 2005-07-15 at 11:24 +0200, Oliver Falk wrote: > > > >>On 07/15/2005 11:14 AM, Tomas Mraz wrote: > >> > >>>And moreover the pam_abl binary should be probably installed in /sbin > >>>and not /usr/sbin as you suggest by using %{_sbindir}. > >> > >>Any *good* reason for installing it in /sbin, rather than /usr/sbin? > > > > For consistency with other pam utilities? Such as pam_tally, > > pam_timestamp_check, pam_console_apply. > > rpm -qpl pam_krb5 | grep bin > /usr/bin/afs5log > > rpm -qpl pam_mount | grep bin > /usr/bin/autoehd > /usr/bin/mkehd > /usr/bin/mount.crypt > /usr/bin/mount_ehd > /usr/bin/passwdehd > /usr/bin/umount.crypt > /usr/sbin/pmvarrun > > So normally, all pam_* binaries, that don't belong to the base pam > package, are not install ind /bin or /sbin. > > Also the pam_abl binary is not needed at boot-time, where a possible > nfs-mounted /usr partion get's mounted, so no need to put it in /sbin... > > But it's a cosmetic/design decision, isn't it? :-) Yep, I'd leave the decision on the package maintainer. -- Tomas Mraz From ermeyers at adelphia.net Fri Jul 15 11:49:38 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 15 Jul 2005 07:49:38 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050715061541.C46D2732FC@hormel.redhat.com> References: <20050715061541.C46D2732FC@hormel.redhat.com> Message-ID: <200507150749.50416.ermeyers@adelphia.net> On Friday 15 July 2005 02:15, Jeff Spaleta wrote: > Uhm.. why exactly do i need a web-server-accessories group? ?Why can't > those packages be optional members of the web server group? ? If you > continue this trend of sub-divding groups so that accessory or > optional packages are in their own accessory group... you'll end up > with hundreds of visible groups as you subdivide group definitions. > This is not a good solution. > > The comps definition makes room for "optional" packages in a group.. > it makes perfect sense to me to place accessories into existing groups > and mark them as "optional" so that tools can expose those packages > accordingly. I'm not going to disagree with you. This is a discussion. I was thinking purely from the perspective of the user wanting a web-server, versus the user wanting an addon to a webserver. The more we mix the fuzzier the group will be. It was an example. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Jul 15 11:50:59 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 15 Jul 2005 06:50:59 -0500 Subject: Bugzilla usage Message-ID: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> Hi All, So this is more of a procedural question, but I thought I'd ask. I've got a bug that has been found and fixed in the latest release of a package. The bugzilla entry was opened against devel, but it's also present in FE-3 and FE-4 since the same package is used across all of them. So now that the bug is fixed, I intend to mark it CURRENTRELEASE. But if someone runs a bugzilla query for this bug, there is no indication at first glance that it's also been fixed for FE-3 and FE-4. So should I: a) clone the bug for FE-3 and FE-4 marking both of them as CURRENTRELEASE as well b) just comment in the original bug that it has been fixed in all versions of FE c) not worry so much about it and get a life Thoughts? josh From oliver at linux-kernel.at Fri Jul 15 12:04:32 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 14:04:32 +0200 Subject: Bugzilla usage In-Reply-To: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> Message-ID: <42D7A650.9070009@linux-kernel.at> On 07/15/2005 01:50 PM, Josh Boyer wrote: > Hi All, > > So this is more of a procedural question, but I thought I'd ask. I've > got a bug that has been found and fixed in the latest release of a > package. The bugzilla entry was opened against devel, but it's also > present in FE-3 and FE-4 since the same package is used across all of > them. > > So now that the bug is fixed, I intend to mark it CURRENTRELEASE. But > if someone runs a bugzilla query for this bug, there is no indication at > first glance that it's also been fixed for FE-3 and FE-4. So should I: > > a) clone the bug for FE-3 and FE-4 marking both of them as > CURRENTRELEASE as well > > b) just comment in the original bug that it has been fixed in all > versions of FE > > c) not worry so much about it and get a life > > Thoughts? c). If you also fix it for FE3 and FE4. If someone with an older version encounters this bug on FE3/4, he will - hopefully - first update his package and not first go to Bugzilla and query for this bug. :-) And if he really does, you can mark the bug as a duplicate of 'current' bug in Bugzilla and close it with CURRENTRELEASE. My 2 cent. At least I would do it this way. Best, Oliver From ermeyers at adelphia.net Fri Jul 15 12:12:48 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 15 Jul 2005 08:12:48 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050715061541.C46D2732FC@hormel.redhat.com> References: <20050715061541.C46D2732FC@hormel.redhat.com> Message-ID: <200507150813.00239.ermeyers@adelphia.net> On Friday 15 July 2005 02:15, Matthew Miller wrote: >Just to clarify -- I think Component is a better name for Logical/Task >groups, not for the "Typal" groups (which maybe, following Freshmeat, could >be called "Troves"). > >A "Web Server" component/logical/task group could be something like the >existing one, containing httpd, httpd-suexec, mod_*, php-*, webalizer, etc. > >Then, a package like httpd would also be in various typal/trove groups: >Daemon, HTTP server, Internet Server. The package webalizer would be in >Console, Log Analizer, Web Tool. (Or something like that.) I'm not going to disagree with you. This is a discussion. I used K.I.S.S. to come up with the names for the three groupings. Three adjectives in the dictionary. 1. Alphabetical grouping 2. Typal grouping 3. Logical grouping http://www.hyperdictionary.com/search.aspx?define=trove Component and Task are cool, but they're not adjectives. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Fri Jul 15 12:15:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jul 2005 08:15:06 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507150749.50416.ermeyers@adelphia.net> References: <20050715061541.C46D2732FC@hormel.redhat.com> <200507150749.50416.ermeyers@adelphia.net> Message-ID: <604aa791050715051538d2c92d@mail.gmail.com> On 7/15/05, Eric R. Meyers wrote: > I'm not going to disagree with you. This is a discussion. I was thinking > purely from the perspective of the user wanting a web-server, versus the user > wanting an addon to a webserver. The more we mix the fuzzier the group will > be. It was an example. And if micro catagorize across the whole package space to that extent you will have hundreds of groups in a flat list. For all the tools that are group aware, this is a untenable situation for UI. You can't just think about repoview... you have to think about how this is going to look in anaconda or s-c-packages (or whatever replaces s-c-packages) as these tools present groups to users. 200 groups exposed during a yum enabled anaconda based install.. is not going to be a good thing. -jef From mpeters at mac.com Fri Jul 15 12:14:33 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 15 Jul 2005 05:14:33 -0700 Subject: Bugzilla usage In-Reply-To: <42D7A650.9070009@linux-kernel.at> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> <42D7A650.9070009@linux-kernel.at> Message-ID: <1121429673.2665.34.camel@locolhost.localdomain> On Fri, 2005-07-15 at 14:04 +0200, Oliver Falk wrote: > On 07/15/2005 01:50 PM, Josh Boyer wrote: > > Hi All, > > > > So this is more of a procedural question, but I thought I'd ask. I've > > got a bug that has been found and fixed in the latest release of a > > package. The bugzilla entry was opened against devel, but it's also > > present in FE-3 and FE-4 since the same package is used across all of > > them. > > > > So now that the bug is fixed, I intend to mark it CURRENTRELEASE. But > > if someone runs a bugzilla query for this bug, there is no indication at > > first glance that it's also been fixed for FE-3 and FE-4. So should I: > > > > a) clone the bug for FE-3 and FE-4 marking both of them as > > CURRENTRELEASE as well > > > > b) just comment in the original bug that it has been fixed in all > > versions of FE > > > > c) not worry so much about it and get a life > > > > Thoughts? > > c). If you also fix it for FE3 and FE4. > > If someone with an older version encounters this bug on FE3/4, he will - > hopefully - first update his package and not first go to Bugzilla and > query for this bug. :-) And if he really does, you can mark the bug as a > duplicate of 'current' bug in Bugzilla and close it with CURRENTRELEASE. related question - are we suppose to indicate the bug number in the changelog? I see that sometimes in core packages when a patch is applied, but I don't think I've seen it when it is fixed via a upstream version. From alex at dalloz.de Fri Jul 15 12:20:52 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Fri, 15 Jul 2005 14:20:52 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D769C8.8070808@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> Message-ID: <1121430052.27608.60.camel@serendipity.dogma.lan> Am Fr, den 15.07.2005 schrieb Oliver Falk um 9:46: > Hi Alexander! Hello Oliver! Starting with a friendly thank you for your review. > Attached is a patch with recommended changes. You don't have to apply > all the whitespace stuff I added, it was just some cosmetic... > > But: > * Macro usage was inconsitant Will take care of this in future. > * At some points macros weren't used (eg. _sysconfdir} Ok, found the note in the packaging guideline, now as you remarks it. (Still not all the rules flooding through my veins :) An additional question regarding macros: -should %{name} be used anywhere else than in BuildRoot and if setup must use the "-n" switch in %prep? From reading other .spec files I have the impression %{name} isn't used wherever possible. - how about using %{__make}, %{__install} or %{__rm}? Is there a general guideline about those macros? Noted: both questions not only directed to you Oliver - I appreciate advises by anyone willing to teach me. > * Added a fine for the reldate (even if it will not live very long) Done. > * Moved pam_abl from /sbin to /usr/sbin - you don't need this before a > possible external /usr gets mounted. Followed your and Tomas' conversation about this. When I originally decided for /sbin I did this - like Tomas noted - because pam_tally (similar purpose like pam_abl) and others are in /sbin. I see your point Oliver and the one is as valid - probably weighting stronger from general point of FHS. So: %{_sbindir}. > Oliver Renewed src.rpm and spec: http://www.uni-x.org/pam_abl-0.2.2-2.src.rpm http://www.uni-x.org/pam_abl.spec Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ermeyers at adelphia.net Fri Jul 15 12:22:32 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 15 Jul 2005 08:22:32 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050715061541.C46D2732FC@hormel.redhat.com> References: <20050715061541.C46D2732FC@hormel.redhat.com> Message-ID: <200507150822.54491.ermeyers@adelphia.net> On Friday 15 July 2005 02:15, seth vidal wrote: >why on earth would you do anything in perl :) Because "Where do you want to go today?" happens. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Fri Jul 15 12:32:17 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 14:32:17 +0200 Subject: Bugzilla usage In-Reply-To: <1121429673.2665.34.camel@locolhost.localdomain> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> <42D7A650.9070009@linux-kernel.at> <1121429673.2665.34.camel@locolhost.localdomain> Message-ID: <42D7ACD1.7000104@linux-kernel.at> On 07/15/2005 02:14 PM, Michael A. Peters wrote: > On Fri, 2005-07-15 at 14:04 +0200, Oliver Falk wrote: > >>On 07/15/2005 01:50 PM, Josh Boyer wrote: >> >>>Hi All, >>> >>>So this is more of a procedural question, but I thought I'd ask. I've >>>got a bug that has been found and fixed in the latest release of a >>>package. The bugzilla entry was opened against devel, but it's also >>>present in FE-3 and FE-4 since the same package is used across all of >>>them. >>> >>>So now that the bug is fixed, I intend to mark it CURRENTRELEASE. But >>>if someone runs a bugzilla query for this bug, there is no indication at >>>first glance that it's also been fixed for FE-3 and FE-4. So should I: >>> >>>a) clone the bug for FE-3 and FE-4 marking both of them as >>>CURRENTRELEASE as well >>> >>>b) just comment in the original bug that it has been fixed in all >>>versions of FE >>> >>>c) not worry so much about it and get a life >>> >>>Thoughts? >> >>c). If you also fix it for FE3 and FE4. >> >>If someone with an older version encounters this bug on FE3/4, he will - >>hopefully - first update his package and not first go to Bugzilla and >>query for this bug. :-) And if he really does, you can mark the bug as a >>duplicate of 'current' bug in Bugzilla and close it with CURRENTRELEASE. > > > related question - are we suppose to indicate the bug number in the > changelog? > I see that sometimes in core packages when a patch is applied, but I > don't think I've seen it when it is fixed via a upstream version. If you have to change something in your specfile, because of a Bugzilla entry, then note the Bugzilla #. If there's a fix in the upstream version, yes, you can note it, and it's maybe no bad idea to note it, so users know about it. Best, Oliver From byte at aeon.com.my Fri Jul 15 12:30:44 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 15 Jul 2005 05:30:44 -0700 Subject: Bugzilla usage In-Reply-To: <1121429673.2665.34.camel@locolhost.localdomain> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> <42D7A650.9070009@linux-kernel.at> <1121429673.2665.34.camel@locolhost.localdomain> Message-ID: <1121430644.3299.114.camel@potter.soho.bytebot.net> On Fri, 2005-07-15 at 05:14 -0700, Michael A. Peters wrote: > > related question - are we suppose to indicate the bug number in the > changelog? That would be good yes (we do that in Extras packages too) > I see that sometimes in core packages when a patch is applied, but I > don't think I've seen it when it is fixed via a upstream version. If its fixed upstream we just say "new upstream release", unless someone filed a bug saying "oi, where's my new upstream release?", in which case you can say: - New upstream release (#nnnnnn) if you really want to. -- Colin Charles, http://www.bytebot.net/ From paul at city-fan.org Fri Jul 15 12:41:24 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 15 Jul 2005 13:41:24 +0100 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121430052.27608.60.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> Message-ID: <42D7AEF4.3070400@city-fan.org> Alexander Dalloz wrote: > An additional question regarding macros: > -should %{name} be used anywhere else than in BuildRoot and if setup > must use the "-n" switch in %prep? From reading other .spec files I have > the impression %{name} isn't used wherever possible. This is largely a matter of clarity. Since %{name} is the name of the package, it's hardly likely to change so the value of using the macro is doubtful. I don't think you'd get too many objections if you used it elsewhere though. > - how about using %{__make}, %{__install} or %{__rm}? Is there a general > guideline about those macros? This is more a matter of personal preference. I prefer to use them throughout; others prefer not to use them at all. I believe both approaches are fine but be consistent throughout a spec file. Either use the macros everywhere or don't use them at all. Paul. From skvidal at phy.duke.edu Fri Jul 15 12:48:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 15 Jul 2005 08:48:13 -0400 Subject: buildsystem test results Message-ID: <1121431694.22260.55.camel@cutter> Hi Folks, I pushed all the packages that were in tobuild back through the new buildsystem last night. Here are the packages that caused a problem: moodss: (all) Whoever checked in the last changes forgot to upload the tarball. scim-anthy: (ppc) http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ scim: (x86_64) http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ barcode: (x86_64) http://buildsys.fedoraproject.org/logs//devel/25-barcode-0.98-6.fc5/ gkrellm-freq: (ppc) http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ Take a look at the build.log and let me know if the failure reason seems more like the fault of the buildsys or more like just a packaging/code issue. Somethings to keep in mind: 1. we're drawing from a normal rawhide mirror so it should be newest or nearly newest rawhide. (within 1 day of current) 2. the x86_64 chroots has i386, i686, athlon, i586, and i486 excluded from its trees. So you should not see any of those conflicts anymore. 3. everything is being built in mock so it should operate for builds just like it would on your local system. 4. there are still some packages building and I'll report any other failures as I find them. thanks, -sv From oliver at linux-kernel.at Fri Jul 15 12:53:23 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 14:53:23 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121430052.27608.60.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> Message-ID: <42D7B1C3.9060009@linux-kernel.at> Hi Alexander! On 07/15/2005 02:20 PM, Alexander Dalloz wrote: > Am Fr, den 15.07.2005 schrieb Oliver Falk um 9:46: > Starting with a friendly thank you for your review. My job, isn't it? :-) Just jokein'. You're welcome! >>Attached is a patch with recommended changes. You don't have to apply >>all the whitespace stuff I added, it was just some cosmetic... >> >>But: >>* Macro usage was inconsitant > > Will take care of this in future. Goooood. :-) >>* At some points macros weren't used (eg. _sysconfdir} > > Ok, found the note in the packaging guideline, now as you remarks it. > (Still not all the rules flooding through my veins :) I guess noone has all rules in his brain. If it would be so, the rpm 'gurus' wouldn't need a reviewer. :-) > An additional question regarding macros: > -should %{name} be used anywhere else than in BuildRoot and if setup > must use the "-n" switch in %prep? From reading other .spec files I have > the impression %{name} isn't used wherever possible. You can use it wherever you need to. I always try to use macros wherever possible and it makes sense to do so. For example, it makes no sense to use macros in %description or in the Summary tag. Just have a look at other package and get a 'feeling' for where to use... > - how about using %{__make}, %{__install} or %{__rm}? Is there a general > guideline about those macros? Some people use it, some don't. I heard from some people. That the make macro isn't available everywhere and therefor it's better not used. And for rm, it usually makes not much sense to use the macro. But actually, there are many packages that use the above mentioned macros (also in FE). Have a look at /usr/lib/rpm/macros. There are many macros that could be used... But maybe it's better to not use ALL of those... > Noted: both questions not only directed to you Oliver - I appreciate > advises by anyone willing to teach me. I hope other people also decide to write you :-) >>* Added a fine for the reldate (even if it will not live very long) > > Done. > >>* Moved pam_abl from /sbin to /usr/sbin - you don't need this before a >>possible external /usr gets mounted. > > Followed your and Tomas' conversation about this. When I originally > decided for /sbin I did this - like Tomas noted - because pam_tally > (similar purpose like pam_abl) and others are in /sbin. I see your point > Oliver and the one is as valid - probably weighting stronger from > general point of FHS. So: %{_sbindir}. It's your decision. If you'd prefer /sbin, this would be also OK... > Renewed src.rpm and spec: > http://www.uni-x.org/pam_abl-0.2.2-2.src.rpm > http://www.uni-x.org/pam_abl.spec Approved. I'll send out the note in a few minutes. Best, Oliver From mattdm at mattdm.org Fri Jul 15 12:58:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 15 Jul 2005 08:58:21 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507150813.00239.ermeyers@adelphia.net> References: <20050715061541.C46D2732FC@hormel.redhat.com> <200507150813.00239.ermeyers@adelphia.net> Message-ID: <20050715125821.GA21584@jadzia.bu.edu> On Fri, Jul 15, 2005 at 08:12:48AM -0400, Eric R. Meyers wrote: > I'm not going to disagree with you. This is a discussion. I used K.I.S.S. to > come up with the names for the three groupings. Three adjectives in the > dictionary. > > 1. Alphabetical grouping > 2. Typal grouping > 3. Logical grouping > > http://www.hyperdictionary.com/search.aspx?define=trove > > Component and Task are cool, but they're not adjectives. Yeah, but "Typal" isn't a very common word (and MW has the primary sense as synonymous with "typical" -- not what you mean). And I think "logical" isn't very good, because it doesn't imply anything about *what the logic is* -- a logical grouping could be pretty much *anything*. As for adjectives, say: Alphabetized group Function group Component group and there you go -- not a problem. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From dwmw2 at infradead.org Fri Jul 15 13:04:39 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jul 2005 14:04:39 +0100 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <1121432679.16070.104.camel@hades.cambridge.redhat.com> On Fri, 2005-07-15 at 08:48 -0400, seth vidal wrote: > scim-anthy: (ppc) > http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ Failed download? + /usr/bin/gzip -dc /builddir/build/SOURCES/scim-anthy-0.5.1.tar.gz + tar -xf - gzip: /builddir/build/SOURCES/scim-anthy-0.5.1.tar.gz: unexpected end of file tar: Read 4307 bytes from - tar: Unexpected EOF in archive tar: Unexpected EOF in archive > gkrellm-freq: (ppc) > http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ Bogus use of asm in the rdtsc() function (which doesn't even seem to be used, afaict). -- dwmw2 From oliver at linux-kernel.at Fri Jul 15 13:07:17 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 15:07:17 +0200 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <42D7B505.7050209@linux-kernel.at> On 07/15/2005 02:48 PM, seth vidal wrote: > Hi Folks, > I pushed all the packages that were in tobuild back through the new > buildsystem last night. Here are the packages that caused a problem: > > moodss: (all) > Whoever checked in the last changes forgot to upload the tarball. > > scim-anthy: (ppc) > http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ gzip: /builddir/build/SOURCES/scim-anthy-0.5.1.tar.gz: unexpected end of file A corrupted tarball!? But it works fine on my machine: [oliver at pils scim-anthy]$ tar xfz scim-anthy-0.5.1.tar.gz [oliver at pils scim-anthy]$ Problem with tar? Or gzip? > scim: (x86_64) > http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ Definitely a package problem: /usr/include/cairo/cairo.h:51: error: expected constructor, destructor, or type conversion before 'extern' /usr/include/pango-1.0/pango/pangocairo.h:62: error: variable or field 'pango_cairo_update_context' declared void /usr/include/pango-1.0/pango/pangocairo.h:62: error: 'cairo_t' was not declared in this scope /usr/include/pango-1.0/pango/pangocairo.h:62: error: 'cr' was not declared in this scope /usr/include/pango-1.0/pango/pangocairo.h:63: error: expected primary-expression before '*' token /usr/include/pango-1.0/pango/pangocairo.h:63: error: 'context' was not declared in this scope > barcode: (x86_64) > http://buildsys.fedoraproject.org/logs//devel/25-barcode-0.98-6.fc5/ ls: barcode.aux: No such file or directory ls: barcode.aux: No such file or directory tex barcode.texinfo barcode.texinfo: No such file or directory make[1]: *** [barcode.info] Error 1 make[1]: *** Waiting for unfinished jobs.... ! I can't find file `barcode.texinfo'. <*> barcode.texinfo make[1]: *** [barcode.dvi] Terminated make[1]: Leaving directory `/builddir/build/BUILD/barcode-0.98/doc' make: *** [doc/barcode.info] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.63466 (%build) Seems to be a package problem as well! > gkrellm-freq: (ppc) > http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ Definitely a package problem: + gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -fsigned-char -fPIC -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2/config -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -c gkfreq.c gkfreq.c: In function 'read_MHz': gkfreq.c:43: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result gkfreq.c: In function 'update_plugin': gkfreq.c:77: warning: passing argument 1 of 'gdk_string_width' from incompatible pointer type gkfreq.c: In function 'rdtsc': gkfreq.c:25: error: impossible constraint in 'asm' error: Bad exit status from /var/tmp/rpm-tmp.59872 (%build) > Take a look at the build.log and let me know if the failure reason seems > more like the fault of the buildsys or more like just a packaging/code > issue. See above notes, but the maintainers - of course - should also check it... > Somethings to keep in mind: > 1. we're drawing from a normal rawhide mirror so it should be newest or > nearly newest rawhide. (within 1 day of current) > > 2. the x86_64 chroots has i386, i686, athlon, i586, and i486 excluded > from its trees. So you should not see any of those conflicts anymore. > > 3. everything is being built in mock so it should operate for builds > just like it would on your local system. > > 4. there are still some packages building and I'll report any other > failures as I find them. 1 - 4: Fine! Best, Oliver From kaboom at oobleck.net Fri Jul 15 13:06:37 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 15 Jul 2005 09:06:37 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa7910507141245678efa18@mail.gmail.com> References: <200507141534.43914.ermeyers@adelphia.net> <604aa7910507141245678efa18@mail.gmail.com> Message-ID: On Thu, 14 Jul 2005, Jeff Spaleta wrote: > On 7/14/05, Eric R. Meyers wrote: > > Gentlemen, > > > > Consensus is building. > > > > I don't care what the grouping views are called. We just need to agree, and we > > are. One of the major issues will be clarifying (defuzzying) the groups, and > > I'll use the group "web-server" as an example. It's a generic name for > > Typal/Component group. It should be made pure to clarify (defuzzify) its > > grouping purpose. So packages like 'apachetop' and 'awstats' will need to be > > moved out into another Typal/Component group called web-server-accessories. > > Uhm.. why exactly do i need a web-server-accessories group? Why can't > those packages be optional members of the web server group? If you > continue this trend of sub-divding groups so that accessory or > optional packages are in their own accessory group... you'll end up > with hundreds of visible groups as you subdivide group definitions. > This is not a good solution. > > The comps definition makes room for "optional" packages in a group.. > it makes perfect sense to me to place accessories into existing groups > and mark them as "optional" so that tools can expose those packages > accordingly. You can get both approaches simply by including the "subgroups" in the main groups and using uservisible as appropriate. Something like: web-server-tools false awstats apachetop web-server true web-server-tools lighttpd thttpd should do the right thing later, chris From ermeyers at adelphia.net Fri Jul 15 13:22:24 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 15 Jul 2005 09:22:24 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050715130703.BC86373621@hormel.redhat.com> References: <20050715130703.BC86373621@hormel.redhat.com> Message-ID: <200507150922.35108.ermeyers@adelphia.net> On Friday 15 July 2005 09:07, Jeff Spaleta wrote: >And if micro catagorize across the whole package space to that extent >you will have hundreds of groups in a flat list. For all the tools >that are group aware, this is a untenable situation for UI. >You can't just think about repoview... you have to think about how >this is going to look in anaconda or s-c-packages (or whatever >replaces s-c-packages) as these tools present groups to users. 200 >groups exposed during a yum enabled anaconda based install.. is not >going to be a good thing. I'm not going to disagree with you. Again. Thanks. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ermeyers at adelphia.net Fri Jul 15 13:30:04 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 15 Jul 2005 09:30:04 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050715130703.BC86373621@hormel.redhat.com> References: <20050715130703.BC86373621@hormel.redhat.com> Message-ID: <200507150930.17253.ermeyers@adelphia.net> On Friday 15 July 2005 09:07, Matthew Miller wrote: >As for adjectives, say: > > Alphabetized group > Function group > Component group > >and there you go -- not a problem. :) I'll buy in! Adding a System Function ... some MP3 player package Adding a System Component ... some suite of packages Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas at bawue.net Fri Jul 15 13:45:21 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 15 Jul 2005 15:45:21 +0200 (CEST) Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: On Fri, 15 Jul 2005, seth vidal wrote: > barcode: (x86_64) > http://buildsys.fedoraproject.org/logs//devel/25-barcode-0.98-6.fc5/ Even though Oliver thinks this might be a package problem, I am not so sure. I just rebuilt that package in mock-0.3.2 on a x86_64 successfully. The package, plus the logs are at http://home.bawue.net/~ixs/barcode/devel/ It looks to me as if the tex you're having is a bit different than the one I get: Excerpt from my log: tex barcode.texinfo This is TeX, Version 3.141592 (Web2C 7.5.4) (./barcode.texinfo (/usr/share/texmf/tex/texinfo/texinfo.tex Loading texinfo [version 2005-01-30.17]: Basics, pdf, fonts, page headings, tables, conditionals, indexing, sectioning, toc, environments, defuns, macros, cross references, insertions, (/usr/share/texmf/tex/generic/epsf/epsf.tex) localization, and turning on texinfo input format.) [1] (Barcode tools) Chapter 1 Chapter 2 [1] [2] Chapter 3 Cross reference values unknown; you must run TeX again. [3] Chapter 4 [4] Chapter 5 [5] [6] Chapter 6 [7] [8] Chapter 7 [9] Chapter 8 [10] (./barcode.toc ) [-1] ) Output written on barcode.dvi (12 pages, 44816 bytes). Your log: tex barcode.texinfo ar: creating libbarcode.a makeinfo barcode.texinfo -o barcode.info Any ideas? Judging by the root.log, the packages being installed are the same. bye, andreas From oliver at linux-kernel.at Fri Jul 15 13:51:18 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jul 2005 15:51:18 +0200 Subject: buildsystem test results In-Reply-To: References: <1121431694.22260.55.camel@cutter> Message-ID: <42D7BF56.9090706@linux-kernel.at> On 07/15/2005 03:45 PM, Andreas Thienemann wrote: > On Fri, 15 Jul 2005, seth vidal wrote: > > >>barcode: (x86_64) >>http://buildsys.fedoraproject.org/logs//devel/25-barcode-0.98-6.fc5/ > > Even though Oliver thinks this might be a package problem, I am not so > sure. > > I just rebuilt that package in mock-0.3.2 on a x86_64 successfully. > > The package, plus the logs are at > http://home.bawue.net/~ixs/barcode/devel/ > > It looks to me as if the tex you're having is a bit different than the one > I get: > > > Excerpt from my log: > > tex barcode.texinfo > This is TeX, Version 3.141592 (Web2C 7.5.4) > (./barcode.texinfo (/usr/share/texmf/tex/texinfo/texinfo.tex > Loading texinfo [version 2005-01-30.17]: Basics, pdf, fonts, page > headings, > tables, conditionals, indexing, sectioning, toc, environments, defuns, > macros, > cross references, insertions, (/usr/share/texmf/tex/generic/epsf/epsf.tex) > localization, and turning on texinfo input format.) [1] (Barcode tools) > Chapter 1 Chapter 2 [1] [2] Chapter 3 > Cross reference values unknown; you must run TeX again. [3] Chapter 4 [4] > Chapter 5 [5] [6] Chapter 6 [7] [8] Chapter 7 [9] Chapter 8 [10] > (./barcode.toc > ) [-1] ) > Output written on barcode.dvi (12 pages, 44816 bytes). Have a look at the log, you also have problems with the documentation: ls: barcode.aux~: No such file or directory texindex: barcode.ps: not a texinfo index file Maybe, it's a x86_64 tetex problem? But I don't believe it's the buildsys... > Your log: > > tex barcode.texinfo > ar: creating libbarcode.a > makeinfo barcode.texinfo -o barcode.info > > Any ideas? Judging by the root.log, the packages being installed are the > same. Best, Oliver From paul at all-the-johnsons.co.uk Fri Jul 15 13:55:42 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Fri, 15 Jul 2005 14:55:42 +0100 Subject: wine for fedora core 4? In-Reply-To: <20050715115121.47cfd92e@python2> References: <1121350975.3618.3.camel@localhost.localdomain> <42D679BF.80608@linux-kernel.at> <1121411204.25163.2.camel@weasel.turre.laiskiainen.org> <42D764AC.6030701@linux-kernel.at> <1121412900.25163.8.camel@weasel.turre.laiskiainen.org> <42D76ACC.9040405@linux-kernel.at> <20050715115121.47cfd92e@python2> Message-ID: <1121435742.10327.4.camel@localhost> Hi, > > Just to let you know, *I'm* not interessted, as I don't use wine - the > > software... :-) > > Anyone the least bit interested could contact Rudolf Kastl, and either > work with him to have him import and maintain his wine package in Extras, > or to cooperate and proxy his changes to Extras. > > http://newrpms.sunsite.dk/ Okay, I'll bite and email Rudolf at some point today with a view to taking over the rpm build for it. TTFN Paul -- "The city of Washington was built on a stagnant swamp some 200 years ago and very little has changed; it stank then and it stinks now. Only today, it is the fetid stench of corruption that hangs in the air" - Simpson, L. Mr Lisa Goes to Washington (1991) Fox. 8F01 (Sep). From jspaleta at gmail.com Fri Jul 15 13:55:56 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jul 2005 09:55:56 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507141534.43914.ermeyers@adelphia.net> <604aa7910507141245678efa18@mail.gmail.com> Message-ID: <604aa79105071506552309f2f7@mail.gmail.com> On 7/15/05, Chris Ricker wrote: > should do the right thing are you sure about that? Are the tools that expose ui for groups able to handling the nesting of visible groups? If the end-user tools can deal sanely with visible sub-groups then great.. if not.. is there a plan to in the future or is this a non-starter? -jef From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 15 14:13:24 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 15 Jul 2005 16:13:24 +0200 Subject: buildsystem test results In-Reply-To: <1121432679.16070.104.camel@hades.cambridge.redhat.com> References: <1121431694.22260.55.camel@cutter> <1121432679.16070.104.camel@hades.cambridge.redhat.com> Message-ID: <20050715161324.3abc37b3@python2> David Woodhouse wrote : > > gkrellm-freq: (ppc) > > http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ > > Bogus use of asm in the rdtsc() function (which doesn't even seem to be > used, afaict). Yeah :-/ I've just tested a rebuild on ppc after removing that useless function, and it works. I'll commit a fix to the devel branch, and will do the same for the other branches if it then builds fine in the build system. BTW, should we still use "make build", or wait for new instructions? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 1.58 1.77 1.63 From tcallawa at redhat.com Fri Jul 15 14:17:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 15 Jul 2005 09:17:08 -0500 Subject: %{?dist} (was: Re: Request for a sponsor and a review of: pam_abl) In-Reply-To: <20050715103235.7f9dc6ed.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D6105C.4000204@linux-kernel.at> <20050714124843.1c9034a6.bugs.michael@gmx.net> <200507151441.37542.symbiont@berlios.de> <20050715103235.7f9dc6ed.bugs.michael@gmx.net> Message-ID: <1121437028.2755.104.camel@localhost.localdomain> On Fri, 2005-07-15 at 10:32 +0200, Michael Schwendt wrote: > Btw, you've still not given a good reason why you want to enforce > %{?dist} on packagers. Where is the value in making it mandatory? As the person who wrote the dist tag documentation, it is not, and never will be, mandatory. :) There are plenty of cases in which it is useful, and plenty of cases when it is not useful. All you have to do is remember the golden rule of branch hierarchy: foo in branch bar must be of a higher n-v-r when compared to foo in branch (bar--). ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From katzj at redhat.com Fri Jul 15 14:59:18 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 15 Jul 2005 10:59:18 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa79105071506552309f2f7@mail.gmail.com> References: <200507141534.43914.ermeyers@adelphia.net> <604aa7910507141245678efa18@mail.gmail.com> <604aa79105071506552309f2f7@mail.gmail.com> Message-ID: <1121439558.15645.39.camel@bree.local.net> On Fri, 2005-07-15 at 09:55 -0400, Jeff Spaleta wrote: > On 7/15/05, Chris Ricker wrote: > > should do the right thing > > are you sure about that? Are the tools that expose ui for groups able > to handling the nesting of visible groups? If the end-user tools can > deal sanely with visible sub-groups then great.. if not.. is there a > plan to in the future or is this a non-starter? Interestingly, I was just having the discussion about being able to nest things somewhat more arbitrarily a couple of days ago. As far as the code is concerned, it's not that hard to do. The more complicated part is how you avoid the UI becoming a problem (doing dialogs on top of dialogs on top of ... gets to be bad quickly). So I'm not against going down that path, but at the same time, I think it does make sense to think about it from a user standpoint and try to come up with something that works better. Jeremy From mpeters at mac.com Fri Jul 15 15:05:26 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 15 Jul 2005 08:05:26 -0700 Subject: %{?dist} (was: Re: Request for a sponsor and a review of: pam_abl) In-Reply-To: <1121437028.2755.104.camel@localhost.localdomain> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <42D6105C.4000204@linux-kernel.at> <20050714124843.1c9034a6.bugs.michael@gmx.net> <200507151441.37542.symbiont@berlios.de> <20050715103235.7f9dc6ed.bugs.michael@gmx.net> <1121437028.2755.104.camel@localhost.localdomain> Message-ID: <1121439926.2665.38.camel@locolhost.localdomain> On Fri, 2005-07-15 at 09:17 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-15 at 10:32 +0200, Michael Schwendt wrote: > > > Btw, you've still not given a good reason why you want to enforce > > %{?dist} on packagers. Where is the value in making it mandatory? > > As the person who wrote the dist tag documentation, it is not, and never > will be, mandatory. :) > > There are plenty of cases in which it is useful, and plenty of cases > when it is not useful. noarch packages that do not have dependencies on specific versions of perl/python/etc are the only situations I can think of where they might not be useful. But I didn't think very hard. From jspaleta at gmail.com Fri Jul 15 15:19:43 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jul 2005 11:19:43 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <1121439558.15645.39.camel@bree.local.net> References: <200507141534.43914.ermeyers@adelphia.net> <604aa7910507141245678efa18@mail.gmail.com> <604aa79105071506552309f2f7@mail.gmail.com> <1121439558.15645.39.camel@bree.local.net> Message-ID: <604aa791050715081950599f2c@mail.gmail.com> On 7/15/05, Jeremy Katz wrote: > So I'm not against going down that path, but at the same time, I think > it does make sense to think about it from a user standpoint and try to > come up with something that works better. Is this a "something better" in terms of how a comps.xml is constructed? Or is this "something better" in terms of how the nesting in comps is exposed? If the nesting in comps that Chris outlined is fine and its just a matter of making the tools sane, then we have a usable path forward for Eric to do his trove-like sub-categorization while avoiding the big flat list of 200+ group definitions. -jef From skvidal at phy.duke.edu Fri Jul 15 15:31:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 15 Jul 2005 11:31:30 -0400 Subject: buildsystem test results In-Reply-To: <20050715161324.3abc37b3@python2> References: <1121431694.22260.55.camel@cutter> <1121432679.16070.104.camel@hades.cambridge.redhat.com> <20050715161324.3abc37b3@python2> Message-ID: <1121441490.26771.19.camel@cutter> On Fri, 2005-07-15 at 16:13 +0200, Matthias Saou wrote: > David Woodhouse wrote : > > > > gkrellm-freq: (ppc) > > > http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ > > > > Bogus use of asm in the rdtsc() function (which doesn't even seem to be > > used, afaict). > > Yeah :-/ I've just tested a rebuild on ppc after removing that useless > function, and it works. I'll commit a fix to the devel branch, and will do > the same for the other branches if it then builds fine in the build system. > > BTW, should we still use "make build", or wait for new instructions? use make build, for now, and I'll post the new instructions 'shortly' -sv From kaboom at oobleck.net Fri Jul 15 15:27:26 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 15 Jul 2005 11:27:26 -0400 (EDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <604aa79105071506552309f2f7@mail.gmail.com> References: <200507141534.43914.ermeyers@adelphia.net> <604aa7910507141245678efa18@mail.gmail.com> <604aa79105071506552309f2f7@mail.gmail.com> Message-ID: On Fri, 15 Jul 2005, Jeff Spaleta wrote: > On 7/15/05, Chris Ricker wrote: > > should do the right thing > > are you sure about that? Are the tools that expose ui for groups able > to handling the nesting of visible groups? If the end-user tools can > deal sanely with visible sub-groups then great.. if not.. is there a > plan to in the future or is this a non-starter? The outline I did was nesting a uservisible=no sub-group inside a uservisible=yes That's currently done and supported by the various tools involved Nesting yes inside yes isn't done at the moment AFAICT (anaconda uses categories instead of groups at that layer).... My thinking is that whenever tools get extended to deal with providing both kinds of views (type and function), functional would hide uservisible=no but type would not later, chris From mattdm at mattdm.org Fri Jul 15 15:41:50 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 15 Jul 2005 11:41:50 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: References: <200507141534.43914.ermeyers@adelphia.net> <604aa7910507141245678efa18@mail.gmail.com> <604aa79105071506552309f2f7@mail.gmail.com> Message-ID: <20050715154150.GA29163@jadzia.bu.edu> On Fri, Jul 15, 2005 at 11:27:26AM -0400, Chris Ricker wrote: > The outline I did was nesting a uservisible=no sub-group inside a > uservisible=yes > That's currently done and supported by the various tools involved > Nesting yes inside yes isn't done at the moment AFAICT (anaconda uses > categories instead of groups at that layer).... In the current comps.xml? Printing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From bugs.michael at gmx.net Fri Jul 15 16:02:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 15 Jul 2005 18:02:53 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121430052.27608.60.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> Message-ID: <20050715180253.634ed615.bugs.michael@gmx.net> On Fri, 15 Jul 2005 14:20:52 +0200, Alexander Dalloz wrote: > - how about using %{__make}, %{__install} or %{__rm}? Is there a general > guideline about those macros? > > Noted: both questions not only directed to you Oliver - I appreciate > advises by anyone willing to teach me. Those are programs which are expected to be in default search PATH. I would not expect "make", "rm" and "install" to be stored in any special location. I would not expect that %{__make} expands to something different than "make" in PATH. So, what these macros do is they create a superfluous dependency on their definition on the package "rpm" and "redhat-rpm-config". And they cause syntax-highlighting to colour them like variables instead of executables. Oliver Falk wrote: > For example, it makes no sense to > use macros in %description or in the Summary tag. But sure it does. %description %{summary}. can make sense. I could think of other examples. From jpo at di.uminho.pt Fri Jul 15 17:05:41 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Fri, 15 Jul 2005 18:05:41 +0100 Subject: [Fwd: Request for review: libdnet] In-Reply-To: <42D7642F.4090601@linux-kernel.at> References: <42CE7705.2090002@linux-kernel.at> <42D544E6.4010503@di.uminho.pt> <42D615E7.8080705@linux-kernel.at> <42D6CC8F.9060408@di.uminho.pt> <42D7642F.4090601@linux-kernel.at> Message-ID: <42D7ECE5.6040402@di.uminho.pt> Oliver Falk wrote: > Hi Jos?! > > On 07/14/2005 10:35 PM, Jos? Pedro Oliveira wrote: > >>> Please review again/approve, new release (2) has just been uploaded: >>> http://filelister.linux-kernel.at/mod_perl?current=/packages/FC_EXTRAS_APPROVAL/libdnet/ >>> >> >> >> Everything looks good. I will send the approval email >> in a couple of hours (after testing it with scanssh). > > > :-) That's exactly why I want this in Extras, I have a scanssh package > as well, that I want to include. With my scanssh it works. > > Thanks for review, let me know (send out approval) if I can cvs-import it. Packaged approved (scanssh 2.1 builds and appears to be working correctly). jpo PS - Approval email following this one. -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From andreas at bawue.net Fri Jul 15 17:51:21 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 15 Jul 2005 19:51:21 +0200 (CEST) Subject: buildsystem test results In-Reply-To: <42D7BF56.9090706@linux-kernel.at> References: <1121431694.22260.55.camel@cutter> <42D7BF56.9090706@linux-kernel.at> Message-ID: On Fri, 15 Jul 2005, Oliver Falk wrote: > Have a look at the log, you also have problems with the documentation: > > ls: barcode.aux~: No such file or directory > texindex: barcode.ps: not a texinfo index file > Yes, I noticed those. However the document I'm interested in (info page) is getting rebuild correctly. > Maybe, it's a x86_64 tetex problem? But I don't believe it's the buildsys... Hmm. I tried building on my local rhel4 notebook, fedora core 4 and rawhide in mock x86_64, rawhide on mock i386. Each build succeeded. So I'm a bit at a loss here why the buildsystem doesn't build the packages while mock here builds the package. In theorie, if my mock installation succeeds, so should seth's buildserver. bye, andreas From bugs.michael at gmx.net Fri Jul 15 18:13:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 15 Jul 2005 20:13:15 +0200 Subject: buildsystem test results In-Reply-To: References: <1121431694.22260.55.camel@cutter> <42D7BF56.9090706@linux-kernel.at> Message-ID: <20050715201315.510cd31c.bugs.michael@gmx.net> On Fri, 15 Jul 2005 19:51:21 +0200 (CEST), Andreas Thienemann wrote: > On Fri, 15 Jul 2005, Oliver Falk wrote: > > > Have a look at the log, you also have problems with the documentation: > > > > ls: barcode.aux~: No such file or directory > > texindex: barcode.ps: not a texinfo index file > > > Yes, I noticed those. However the document I'm interested in (info page) > is getting rebuild correctly. > > > Maybe, it's a x86_64 tetex problem? But I don't believe it's the buildsys... > Hmm. I tried building on my local rhel4 notebook, fedora core 4 and > rawhide in mock x86_64, rawhide on mock i386. > Each build succeeded. > > So I'm a bit at a loss here why the buildsystem doesn't build the packages > while mock here builds the package. > In theorie, if my mock installation succeeds, so should seth's > buildserver. Are you sure it's not an SMP make flags problem? Here it really removes barcode.texinfo before it calls tex on it: cd doc && make gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -Wall -DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1 -DNO_LIBPAPER -c -o sample.o sample.c make[1]: Entering directory `/builddir/build/BUILD/barcode-0.98/doc' sed -f ./infofilter doc.barcode | cat > barcode.texinfo chmod 400 barcode.texinfo # preserve the pdf copy mv -f barcode.pdf PDF 2> /dev/null && \ rm -f *~ *.dvi *.log *.aux \ barcode.*.bak barcode.??? barcode.texinfo && \ mv PDF barcode.pdf; # preserve the ps copy mv barcode.ps PS; rm -f barcode.??; sample.c: In function 'main': sample.c:9: warning: implicit declaration of function 'strcmp' mv PS barcode.ps; touch barcode.oo if test "x`ls barcode.?? barcode.aux`" != "x"; then \ for i in `ls barcode.?? barcode.aux`; do \ cp $i $i~; \ done; \ fi ar r libbarcode.a library.o ean.o code128.o code39.o code93.o i25.o msi.o plessey.o codabar.o ps.o pcl.o ls: barcode.aux: No such file or directory ls: barcode.aux: No such file or directory tex barcode.texinfo ar: creating libbarcode.a makeinfo barcode.texinfo -o barcode.info barcode.texinfo: No such file or directory make[1]: *** [barcode.info] Error 1 make[1]: *** Waiting for unfinished jobs.... From andreas at bawue.net Fri Jul 15 18:32:17 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 15 Jul 2005 20:32:17 +0200 (CEST) Subject: buildsystem test results In-Reply-To: <20050715201315.510cd31c.bugs.michael@gmx.net> References: <1121431694.22260.55.camel@cutter> <42D7BF56.9090706@linux-kernel.at> <20050715201315.510cd31c.bugs.michael@gmx.net> Message-ID: On Fri, 15 Jul 2005, Michael Schwendt wrote: > Are you sure it's not an SMP make flags problem? Here it really > removes barcode.texinfo before it calls tex on it: Great job spotting that. Thx. I didn't think about SMP as my smp machine is running UP right now because of some earlier problems with the buildsystem and threading. I just rebootet into an SMP kernel and behold, I'm seeing the same problem. Fixed in the spec. bye, andreas From paul at all-the-johnsons.co.uk Fri Jul 15 19:01:03 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 15 Jul 2005 20:01:03 +0100 Subject: WINE Message-ID: <1121454063.10327.26.camel@localhost> Hi, Does anyone know of any problems with bringing Wine into FC Extras? I've contacted Rudolf for pointers on building etc and would be interested to know if it's a suitable package. TTFN Paul -- "Some people will do anything for a woman in uniform" - The Doctor - Unregenerate (Big Finish audio) -------------- 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 pnasrat at redhat.com Fri Jul 15 19:18:55 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 15 Jul 2005 15:18:55 -0400 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <1121455135.6104.1.camel@enki.eridu> On Fri, 2005-07-15 at 08:48 -0400, seth vidal wrote: > Hi Folks, > I pushed all the packages that were in tobuild back through the new > buildsystem last night. Here are the packages that caused a problem: Hmm http://buildsys.fedoraproject.org/logs/devel/61-splint-3.1.1-9.fc5/ppc/root.log /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-ppc-core-f5a038c79be4e54f9990b33128bf26957e185fc3/root groupinstall build http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/ppc/repodata/comps.xml: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/comps.xml from core: [Errno 256] No more mirrors to try. Cleaning up... Do I just need to make build again? Paul From orion at cora.nwra.com Fri Jul 15 20:48:19 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Jul 2005 14:48:19 -0600 Subject: Using %{dist} for conditional compilation Message-ID: <42D82113.5030005@cora.nwra.com> Is it kosher to use the %{dist} tag for conditional compilation? The shift from g77 to gfortran in FC3->FC4 has led to the need to compile packages differently for the two distributions. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ivazquez at ivazquez.net Fri Jul 15 21:01:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Jul 2005 17:01:16 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42D82113.5030005@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> Message-ID: <1121461276.10063.11.camel@ignacio.lan> On Fri, 2005-07-15 at 14:48 -0600, Orion Poplawski wrote: > Is it kosher to use the %{dist} tag for conditional compilation? The > shift from g77 to gfortran in FC3->FC4 has led to the need to compile > packages differently for the two distributions. No. Use %{fedora}. It will have an integer value the same as the version of Fedora the package is built for. Even better, since there are separate branches per version it's easy enough to just have the differences in the spec files directly. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jdennis at redhat.com Fri Jul 15 21:14:06 2005 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jul 2005 17:14:06 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <1121461276.10063.11.camel@ignacio.lan> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> Message-ID: <1121462046.4691.47.camel@finch.boston.redhat.com> On Fri, 2005-07-15 at 17:01 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-07-15 at 14:48 -0600, Orion Poplawski wrote: > > Is it kosher to use the %{dist} tag for conditional compilation? The > > shift from g77 to gfortran in FC3->FC4 has led to the need to compile > > packages differently for the two distributions. > > No. Use %{fedora}. It will have an integer value the same as the version > of Fedora the package is built for. Even better, since there are > separate branches per version it's easy enough to just have the > differences in the spec files directly. If the package uses the GNU autotools (e.g. configure) it is better to put the logic for picking a compiler and its parameters into the configure script. This makes it entirely independent of the packaging and distribution. -- John Dennis From qspencer at ieee.org Fri Jul 15 21:20:15 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 15 Jul 2005 16:20:15 -0500 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <1121462046.4691.47.camel@finch.boston.redhat.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <1121462046.4691.47.camel@finch.boston.redhat.com> Message-ID: <42D8288F.1080002@ieee.org> John Dennis wrote: >On Fri, 2005-07-15 at 17:01 -0400, Ignacio Vazquez-Abrams wrote: > > >>On Fri, 2005-07-15 at 14:48 -0600, Orion Poplawski wrote: >> >> >>>Is it kosher to use the %{dist} tag for conditional compilation? The >>>shift from g77 to gfortran in FC3->FC4 has led to the need to compile >>>packages differently for the two distributions. >>> >>> >>No. Use %{fedora}. It will have an integer value the same as the version >>of Fedora the package is built for. Even better, since there are >>separate branches per version it's easy enough to just have the >>differences in the spec files directly. >> >> > >If the package uses the GNU autotools (e.g. configure) it is better to >put the logic for picking a compiler and its parameters into the >configure script. This makes it entirely independent of the packaging >and distribution. > > Yes, but shouldn't that be done in the upstream sources? Sure, an ambitious packager can hack the configure script and send the fixes upstream, but I don't know enough about autotools to do that properly, so if it were me hacking the spec file sounds easier. In this particular case, you know exactly what you're looking for anyway--it's not like an FC3 package needs to be able to compile on cygwin, OSX, *BSD, or something like that. -Quentin From tcallawa at redhat.com Fri Jul 15 21:22:34 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 15 Jul 2005 16:22:34 -0500 Subject: WINE In-Reply-To: <1121454063.10327.26.camel@localhost> References: <1121454063.10327.26.camel@localhost> Message-ID: <1121462554.2755.118.camel@localhost.localdomain> On Fri, 2005-07-15 at 20:01 +0100, Paul wrote: > Hi, > > Does anyone know of any problems with bringing Wine into FC Extras? I've > contacted Rudolf for pointers on building etc and would be interested to > know if it's a suitable package. Wine should be fine for inclusion, presuming it doesn't come packed with windows DLL files these days. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From roland at redhat.com Fri Jul 15 21:25:42 2005 From: roland at redhat.com (Roland McGrath) Date: Fri, 15 Jul 2005 14:25:42 -0700 (PDT) Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: John Dennis's message of Friday, 15 July 2005 17:14:06 -0400 <1121462046.4691.47.camel@finch.boston.redhat.com> Message-ID: <20050715212542.9FE7D1809FC@magilla.sf.frob.com> The cases where conditionals come up in the spec files are for things like different buildrequires, or different --with/--enable options due to being able to use system-supplied versions that are compatible on one FC release and needing to use package-bundled versions on other FC releases. For lots of extras packages, the package itself changes much more often than these differences do, so it really is easier to have a single spec file that uses conditionals than to maintain branched versions of the spec file. From paul at all-the-johnsons.co.uk Fri Jul 15 21:52:02 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Fri, 15 Jul 2005 22:52:02 +0100 Subject: WINE In-Reply-To: <1121462554.2755.118.camel@localhost.localdomain> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> Message-ID: <1121464322.10327.38.camel@localhost> Hi, > > Does anyone know of any problems with bringing Wine into FC Extras? I've > > contacted Rudolf for pointers on building etc and would be interested to > > know if it's a suitable package. > > Wine should be fine for inclusion, presuming it doesn't come packed with > windows DLL files these days. :) There are DLL files in there, but they have never seen a Microsoft person in their life. My only concern is that MS have turned their sights on Wine in their usual "we're not targetting xyz" way before turning their artillery on it! TTFN Paul -- "Some people will do anything for a woman in uniform" - The Doctor - Unregenerate (Big Finish audio) From stickster at gmail.com Fri Jul 15 22:25:35 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 15 Jul 2005 18:25:35 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121376609.2975.3.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> Message-ID: <1121466335.3250.5.camel@localhost.localdomain> On Thu, 2005-07-14 at 17:30 -0400, Paul W. Frields wrote: > On Thu, 2005-07-14 at 16:26 -0400, Paul Nasrat wrote: > > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > > > > > Done, requested cvsextras group membership to go with my other existing > > > ones. Paul N., are you willing to check this over? If not, anyone > > > else? > > > > Review based on http://fedoraproject.org/wiki/PackagingGuidelines it's > > been a while since I did QA. > > > > Source against upstream and independant download: > > > > http://manny.cluecoder.org/packages/nautilus-open-terminal/nautilus-open-terminal-0.4.tar.gz.md5 > > md5 931a50e602f60340a5ed369f50146f36 nautilus-open-terminal-0.4.tar.gz > > > > Source License is GPL, no known legal issues. > > > > Builds locally using rpmbuild and mock - so buildrequires form all > > requirements. > > > > Terminal menu appears after logout/login and using nautilus -q (tested > > both mock built and system built package) > > > > However: > > > > rpmlint gives: > > W: nautilus-open-terminal devel-file-in-non-devel-package /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.a > > E: nautilus-open-terminal > > script-without-shellbang /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.la > > > > Indeed - you probably just want to nuke the .a and .la files > > Done. See 0.4-3 at same location. Sorry I missed the section on > rpmlint; everyone has to start somewhere, I suppose. I'll be sure to > use it in the future (and reread spot's Guidelines). Sorry to reply to myself. New off-Broadway version 0.4-4 fixes other discrepancies from spot's reviewer guidelines: http://rpm.frields.org/FC5/nautilus-open-terminal/ -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 orion at cora.nwra.com Fri Jul 15 22:25:12 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Jul 2005 16:25:12 -0600 Subject: Request for Review: hdf Message-ID: <42D837C8.3000603@cora.nwra.com> This is version 4 for the HDF library. http://www.cora.nwra.com/~orion/fedora/hdf.spec http://www.cora.nwra.com/~orion/fedora/hdf-4.2r1-1.src.rpm It somewhat based on my hdf5 package, so I'm not sure there is enough differentiation in Summary and %description. It also only work on FC4 for now. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From mpeters at mac.com Fri Jul 15 22:28:57 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 15 Jul 2005 15:28:57 -0700 Subject: Using %{dist} for conditional compilation In-Reply-To: <42D82113.5030005@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> Message-ID: <1121466537.2665.41.camel@locolhost.localdomain> On Fri, 2005-07-15 at 14:48 -0600, Orion Poplawski wrote: > Is it kosher to use the %{dist} tag for conditional compilation? No, I don't think so - because %{dist} is not defined on the users machines, only defined on the build machine, in mock. different spec files in the different branches seems best to me. > The > shift from g77 to gfortran in FC3->FC4 has led to the need to compile > packages differently for the two distributions. > From orion at cora.nwra.com Fri Jul 15 22:35:03 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Jul 2005 16:35:03 -0600 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <1121461276.10063.11.camel@ignacio.lan> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> Message-ID: <42D83A17.9060302@cora.nwra.com> Ignacio Vazquez-Abrams wrote: > > No. Use %{fedora}. It will have an integer value the same as the version > of Fedora the package is built for. Even better, since there are > separate branches per version it's easy enough to just have the > differences in the spec files directly. > Could you give an example? I can't find docs on how to use %if in a spec file to compare values. Trying to do something like: %if %{fedora} >= 4 BuildRequires: gcc-gfortran %else BuildRequires: gcc-g77 %endif -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From andreas at bawue.net Fri Jul 15 22:52:08 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 16 Jul 2005 00:52:08 +0200 (CEST) Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42D83A17.9060302@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> Message-ID: On Fri, 15 Jul 2005, Orion Poplawski wrote: > Could you give an example? I can't find docs on how to use %if in a > spec file to compare values. Trying to do something like: %if "%fedora" >= "4" BuildRequires: gcc-gfortran %else BuildRequires: gcc-g77 %endif This should work. bye, andreas From bugs.michael at gmx.net Fri Jul 15 23:10:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 16 Jul 2005 01:10:52 +0200 Subject: Request for review: tcllib In-Reply-To: <42CEC83A.9090100@kobold.org> References: <42CEC83A.9090100@kobold.org> Message-ID: <20050716011052.63ee6296.bugs.michael@gmx.net> On Fri, 08 Jul 2005 11:38:50 -0700, Michael Thomas wrote: > I just discovered that tcllib-1.3 was in FC1 but later removed. I've > imported tcllib -1.7 into CVS and now need a review: Packages removed from Core and brought back to life in Extras don't depend on an explicit review process. But where does tcllib come from? It's not in the FC1 package list. It doesn't list a Red Hat engineer in the spec changelog. It looks like it might come from the fedora.us QA queue, as it's not in the list of released fedora.us packages either. From ermeyers at adelphia.net Sat Jul 16 01:05:11 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Fri, 15 Jul 2005 21:05:11 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ Message-ID: <200507152105.22403.ermeyers@adelphia.net> Could one of you yum experts clarify what I'm seeing here. This is the group spec in your comps.xml: engineering-and-scientific Engineering and Scientific This group includes packages for performing mathematical and scientific computations and plotting, as well as unit conversion. false true blacs blas galculator lapack R R-gnomeGUI scalapack I run: yum --disablerepo=extras-development groupinfo 'Engineering and Scientific' ... Group: Engineering and Scientific Required Groups: (I don't see this) Base (I don't see this) Default Packages: (I don't see this) units (I don't see this) gnuplot (I don't see this) Optional Packages (I see this) lapack (I see this) blas (I see this) blacs (I see this) galculator (I see this) R-gnomeGUI (I see this) R (I see this) scalapack (I see this) lam (I don't see this) pvm (I don't see this) Please explain. Thanks Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pnasrat at redhat.com Sat Jul 16 01:34:33 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 15 Jul 2005 21:34:33 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121466335.3250.5.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> Message-ID: <1121477674.3236.25.camel@enki.eridu> On Fri, 2005-07-15 at 18:25 -0400, Paul W. Frields wrote: > On Thu, 2005-07-14 at 17:30 -0400, Paul W. Frields wrote: > > On Thu, 2005-07-14 at 16:26 -0400, Paul Nasrat wrote: > > > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > > > > > > > Done, requested cvsextras group membership to go with my other existing > > > > ones. Paul N., are you willing to check this over? If not, anyone > > > > else? > > > > > > Review based on http://fedoraproject.org/wiki/PackagingGuidelines it's > > > been a while since I did QA. > > > > > > Source against upstream and independant download: > > > > > > http://manny.cluecoder.org/packages/nautilus-open-terminal/nautilus-open-terminal-0.4.tar.gz.md5 > > > md5 931a50e602f60340a5ed369f50146f36 nautilus-open-terminal-0.4.tar.gz > > > > > > Source License is GPL, no known legal issues. > > > > > > Builds locally using rpmbuild and mock - so buildrequires form all > > > requirements. > > > > > > Terminal menu appears after logout/login and using nautilus -q (tested > > > both mock built and system built package) > > > > > > However: > > > > > > rpmlint gives: > > > W: nautilus-open-terminal devel-file-in-non-devel-package /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.a > > > E: nautilus-open-terminal > > > script-without-shellbang /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.la > > > > > > Indeed - you probably just want to nuke the .a and .la files > > > > Done. See 0.4-3 at same location. Sorry I missed the section on > > rpmlint; everyone has to start somewhere, I suppose. I'll be sure to > > use it in the future (and reread spot's Guidelines). > > Sorry to reply to myself. New off-Broadway version 0.4-4 fixes other > discrepancies from spot's reviewer guidelines: > > http://rpm.frields.org/FC5/nautilus-open-terminal/ I see nothing... and I really want to get this through so we can concentrate on possibilities for it in Core... Paul From toshio at tiki-lounge.com Sat Jul 16 01:55:55 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 15 Jul 2005 21:55:55 -0400 Subject: Bugzilla usage In-Reply-To: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> Message-ID: <1121478955.3128.59.camel@localhost> On Fri, 2005-07-15 at 06:50 -0500, Josh Boyer wrote: > Hi All, > > So this is more of a procedural question, but I thought I'd ask. I've > got a bug that has been found and fixed in the latest release of a > package. The bugzilla entry was opened against devel, but it's also > present in FE-3 and FE-4 since the same package is used across all of > them. > > So now that the bug is fixed, I intend to mark it CURRENTRELEASE. But > if someone runs a bugzilla query for this bug, there is no indication at > first glance that it's also been fixed for FE-3 and FE-4. Any reason not to close it ERRATA and note which FE versions the ERRATA has been released for? -Toshio -------------- 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 jspaleta at gmail.com Sat Jul 16 01:57:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jul 2005 21:57:13 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507152105.22403.ermeyers@adelphia.net> References: <200507152105.22403.ermeyers@adelphia.net> Message-ID: <604aa791050715185750b774a2@mail.gmail.com> On 7/15/05, Eric R. Meyers wrote: > yum --disablerepo=extras-development groupinfo 'Engineering and Scientific' you disabled extras-development but development is still enabled. The comps files you show is from extras-development. As a result you are seeing the members of Engineering and Scientific from the Core development tree. Assuming you have a normal yum configure for the development tree. If you want to just see the members from extras development you would do: yum --disablerepo=development groupinfo 'Engineering and Scientific' Core has a comps file and Extras as a seperate comps file. Yum merges groups listed in both files. Look at the Enginnering and Scieintific group definition in both these files: http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/repodata/comps.xml http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/repodata/comps.xml From petersen at redhat.com Sat Jul 16 02:26:45 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 16 Jul 2005 11:26:45 +0900 Subject: Request for review: tcllib In-Reply-To: <20050716011052.63ee6296.bugs.michael@gmx.net> References: <42CEC83A.9090100@kobold.org> <20050716011052.63ee6296.bugs.michael@gmx.net> Message-ID: <42D87065.7070703@redhat.com> Michael Schwendt wrote: > On Fri, 08 Jul 2005 11:38:50 -0700, Michael Thomas wrote: > >>I just discovered that tcllib-1.3 was in FC1 but later removed. I've >>imported tcllib -1.7 into CVS and now need a review: Right: sorry I meant to follow up earlier... > But where does tcllib come from? It's not in the FC1 package list. It > doesn't list a Red Hat engineer in the spec changelog. It looks like it > might come from the fedora.us QA queue, as it's not in the list of > released fedora.us packages either. tcllib was part of the jumbo tcltk package until FC1. When tcltk was split up into separate source packages tcllib was dropped from Core. Later a few people requested it back, but it was suggested that it should into Extras. And here we are. :-) Jens From petersen at redhat.com Sat Jul 16 03:18:30 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 16 Jul 2005 12:18:30 +0900 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <42D87C86.7080804@redhat.com> seth vidal wrote: > scim-anthy: (ppc) > http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ 22-scim-anthy-0.5.1-2.fc4 built fine. :) > scim: (x86_64) > http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ Seems to be some problem related to cairo and C++. (Built fine the other day in the fc5 buildroot in the FC buildsystem though fwiw.) Thanks, Jens From stickster at gmail.com Sat Jul 16 03:21:10 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 15 Jul 2005 23:21:10 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121477674.3236.25.camel@enki.eridu> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> Message-ID: <1121484070.3014.26.camel@localhost.localdomain> On Fri, 2005-07-15 at 21:34 -0400, Paul Nasrat wrote: > On Fri, 2005-07-15 at 18:25 -0400, Paul W. Frields wrote: > > On Thu, 2005-07-14 at 17:30 -0400, Paul W. Frields wrote: > > > On Thu, 2005-07-14 at 16:26 -0400, Paul Nasrat wrote: > > > > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > > > > > > > > > Done, requested cvsextras group membership to go with my other existing > > > > > ones. Paul N., are you willing to check this over? If not, anyone > > > > > else? > > > > > > > > Review based on http://fedoraproject.org/wiki/PackagingGuidelines it's > > > > been a while since I did QA. > > > > > > > > Source against upstream and independant download: > > > > > > > > http://manny.cluecoder.org/packages/nautilus-open-terminal/nautilus-open-terminal-0.4.tar.gz.md5 > > > > md5 931a50e602f60340a5ed369f50146f36 nautilus-open-terminal-0.4.tar.gz > > > > > > > > Source License is GPL, no known legal issues. > > > > > > > > Builds locally using rpmbuild and mock - so buildrequires form all > > > > requirements. > > > > > > > > Terminal menu appears after logout/login and using nautilus -q (tested > > > > both mock built and system built package) > > > > > > > > However: > > > > > > > > rpmlint gives: > > > > W: nautilus-open-terminal devel-file-in-non-devel-package /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.a > > > > E: nautilus-open-terminal > > > > script-without-shellbang /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.la > > > > > > > > Indeed - you probably just want to nuke the .a and .la files > > > > > > Done. See 0.4-3 at same location. Sorry I missed the section on > > > rpmlint; everyone has to start somewhere, I suppose. I'll be sure to > > > use it in the future (and reread spot's Guidelines). > > > > Sorry to reply to myself. New off-Broadway version 0.4-4 fixes other > > discrepancies from spot's reviewer guidelines: > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > I see nothing... > > and I really want to get this through so we can concentrate on > possibilities for it in Core... That's decidedly weird, since it's there and I just tested it from an external shell account. Are you using a wacky browser (or wacky settings) that reject frames? I see some entries in my access log purporting to be from a w3m client, which may or may not be you. In any case, you should be able to use: http://www2.frields.org:8080/rpm/FC5/nautilus-open-terminal/ -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 jspaleta at gmail.com Sat Jul 16 03:34:41 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jul 2005 23:34:41 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121477674.3236.25.camel@enki.eridu> References: <1121143049.3521.16.camel@localhost.localdomain> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> Message-ID: <604aa79105071520341f1e0ad1@mail.gmail.com> On 7/15/05, Paul Nasrat wrote: > I see nothing... > > and I really want to get this through so we can concentrate on > possibilities for it in Core... It was there for me... i grabbed the src and built it with mock. installs fine. I haven't had time to do the full review yet this evening... -jef From petersen at redhat.com Sat Jul 16 03:43:46 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 16 Jul 2005 12:43:46 +0900 Subject: buildsystem test results In-Reply-To: <42D87C86.7080804@redhat.com> References: <1121431694.22260.55.camel@cutter> <42D87C86.7080804@redhat.com> Message-ID: <42D88272.9090205@redhat.com> Jens Petersen wrote: >>scim: (x86_64) >>http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ > > Seems to be some problem related to cairo and C++. > (Built fine the other day in the fc5 buildroot in the FC buildsystem though fwiw.) Erm, well not any more anyway... Jens From mccann0011 at hotmail.com Sat Jul 16 04:38:59 2005 From: mccann0011 at hotmail.com (Shawn McCann) Date: Fri, 15 Jul 2005 21:38:59 -0700 Subject: Request for review: libgeotiff Message-ID: As part of an effort to add some GIS tools to extras (namely Quantum GIS and GRASS), I've packaged up libgeotiff for extras: SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm Libgeotiff is a public domain library normally hosted on top of libtiff for reading, and writing GeoTIFF information tags. Thanks Shawn From jwboyer at jdub.homelinux.org Sat Jul 16 13:05:26 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 16 Jul 2005 08:05:26 -0500 Subject: Bugzilla usage In-Reply-To: <1121478955.3128.59.camel@localhost> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> <1121478955.3128.59.camel@localhost> Message-ID: <1121519127.2685.50.camel@yoda.jdub.homelinux.org> On Fri, 2005-07-15 at 21:55 -0400, Toshio Kuratomi wrote: > On Fri, 2005-07-15 at 06:50 -0500, Josh Boyer wrote: > > Hi All, > > > > So this is more of a procedural question, but I thought I'd ask. I've > > got a bug that has been found and fixed in the latest release of a > > package. The bugzilla entry was opened against devel, but it's also > > present in FE-3 and FE-4 since the same package is used across all of > > them. > > > > So now that the bug is fixed, I intend to mark it CURRENTRELEASE. But > > if someone runs a bugzilla query for this bug, there is no indication at > > first glance that it's also been fixed for FE-3 and FE-4. > > Any reason not to close it ERRATA and note which FE versions the ERRATA > has been released for? Because the bug was fixed in a new upstream release, so the package had the bug fixed by updating to the new release. Or do the {CURRENT,NEXT}RELEASE resolutions indicate that the bug was fixed in the current release of Extras its self? josh From jspaleta at gmail.com Sat Jul 16 13:21:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 16 Jul 2005 09:21:33 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121484070.3014.26.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> <1121484070.3014.26.camel@localhost.localdomain> Message-ID: <604aa79105071606213cbd7bda@mail.gmail.com> On 7/15/05, Paul W. Frields wrote: > http://www2.frields.org:8080/rpm/FC5/nautilus-open-terminal/ I ran over the review guidelines list and I only see on problem. Doesn't this file count as a shared object? /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.so If so you need a post and postun sections like: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig The 0.4-4 changelog entry seems to imply you tried to fix this scriptlet issue when you added the find_lang call. Maybe you just accidently left the post and postun sections out? Anyway adding the scriptlets to run ldconfig is the only thing left I see in the spec. -jef From stickster at gmail.com Sat Jul 16 14:00:17 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 16 Jul 2005 10:00:17 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <604aa79105071606213cbd7bda@mail.gmail.com> References: <1121143049.3521.16.camel@localhost.localdomain> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> <1121484070.3014.26.camel@localhost.localdomain> <604aa79105071606213cbd7bda@mail.gmail.com> Message-ID: <1121522417.2975.6.camel@localhost.localdomain> On Sat, 2005-07-16 at 09:21 -0400, Jeff Spaleta wrote: > On 7/15/05, Paul W. Frields wrote: > > http://www2.frields.org:8080/rpm/FC5/nautilus-open-terminal/ > > I ran over the review guidelines list and I only see on problem. > > Doesn't this file count as a shared object? > /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.so > > If so you need a post and postun sections like: > > %post -p /sbin/ldconfig > > %postun -p /sbin/ldconfig I asked Paul Nasrat about this -- offlist, for which I apologize -- and he replied thusly: "I don't think we need /sbin/ldconfig, as I assume it gets dlopen'ed by nautilus." I notice that ldconfig is not configured to even look through /usr/lib/nautilus/extensions-1.0/, so that's another reason not to include it. > The 0.4-4 changelog entry seems to imply you tried to fix this > scriptlet issue when you added the find_lang call. Maybe you just > accidently left the post and postun sections out? > > Anyway adding the scriptlets to run ldconfig is the only thing left I > see in the spec. My changelog entry was written prior to Paul N.'s reply, and I unfortunately forgot to edit it before rebuilding. I can produce a 0.4-5 if that's necessary; thanks for your patience, since I'm new at this. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Sat Jul 16 14:12:10 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 16 Jul 2005 09:12:10 -0500 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <604aa79105071606213cbd7bda@mail.gmail.com> References: <1121143049.3521.16.camel@localhost.localdomain> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> <1121484070.3014.26.camel@localhost.localdomain> <604aa79105071606213cbd7bda@mail.gmail.com> Message-ID: <1121523130.2755.123.camel@localhost.localdomain> On Sat, 2005-07-16 at 09:21 -0400, Jeff Spaleta wrote: > On 7/15/05, Paul W. Frields wrote: > > http://www2.frields.org:8080/rpm/FC5/nautilus-open-terminal/ > > I ran over the review guidelines list and I only see on problem. > > Doesn't this file count as a shared object? > /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.so No, it doesn't. I really need to add some clarification on that to the documentation. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bdpepple at ameritech.net Sat Jul 16 14:16:53 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 16 Jul 2005 10:16:53 -0400 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050714212139.296a473d@python2> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> Message-ID: <1121523413.17248.4.camel@shuttle.273piedmont.com> On Thu, 2005-07-14 at 21:21 +0200, Matthias Saou wrote: > Well, in that case, I'd be interested in hearing your comments regarding > the possibility of having a "gkrellm-xmms" package that would obsolete > "gkrellmms". You can find such a package next to the "gkrellm-bmp" one. A > quick review of both would be much appreciated too ;-) > The specs look ok, but is there any reason for not following the upstream name? According to the wiki, we should try to follow the upstream name, and I don't see any compelling reason not to follow that. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 jspaleta at gmail.com Sat Jul 16 14:22:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 16 Jul 2005 10:22:03 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121523130.2755.123.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> <1121484070.3014.26.camel@localhost.localdomain> <604aa79105071606213cbd7bda@mail.gmail.com> <1121523130.2755.123.camel@localhost.localdomain> Message-ID: <604aa7910507160722767e906e@mail.gmail.com> On 7/16/05, Tom 'spot' Callaway wrote: > No, it doesn't. I really need to add some clarification on that to the > documentation. There is a deeper unasked question lurking about when to know if an entry in /etc/ld.so.conf.d/ is going to be appropriate or if the library is meant to be strictly a dlopened plugin for something else. Luckily its an an unasked question so there is no need to answer it yet. In this case I'm just being and idiot... its obvious now that I have the second cup of coffee that that directory is dedicated for nautilus plugins. -jef"it takes me 3 cups of coffee to be aware enough to realize I've put my shirt on inside out"spaleta From mattdm at mattdm.org Sat Jul 16 14:30:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 16 Jul 2005 10:30:10 -0400 Subject: Bugzilla usage In-Reply-To: <1121519127.2685.50.camel@yoda.jdub.homelinux.org> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> <1121478955.3128.59.camel@localhost> <1121519127.2685.50.camel@yoda.jdub.homelinux.org> Message-ID: <20050716143010.GA6698@jadzia.bu.edu> On Sat, Jul 16, 2005 at 08:05:26AM -0500, Josh Boyer wrote: > Or do the {CURRENT,NEXT}RELEASE resolutions indicate that the bug was > fixed in the current release of Extras its self? Yeah, that. See -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From bugs.michael at gmx.net Sat Jul 16 14:51:49 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 16 Jul 2005 16:51:49 +0200 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121522417.2975.6.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121477674.3236.25.camel@enki.eridu> <1121484070.3014.26.camel@localhost.localdomain> <604aa79105071606213cbd7bda@mail.gmail.com> <1121522417.2975.6.camel@localhost.localdomain> Message-ID: <20050716165149.0431234d.bugs.michael@gmx.net> On Sat, 16 Jul 2005 10:00:17 -0400, Paul W. Frields wrote: > > I ran over the review guidelines list and I only see on problem. > > > > Doesn't this file count as a shared object? > > /usr/lib/nautilus/extensions-1.0/libnautilus-open-terminal.so > > > > If so you need a post and postun sections like: > > > > %post -p /sbin/ldconfig > > > > %postun -p /sbin/ldconfig > > I asked Paul Nasrat about this -- offlist, for which I apologize -- and > he replied thusly: > > "I don't think we need /sbin/ldconfig, as I assume it gets dlopen'ed > by nautilus." That's not the primary reason, however, as dlopen may use the same dynamic linker cache if no absolute path is specified. > I notice that ldconfig is not configured to even look > through /usr/lib/nautilus/extensions-1.0/, so that's another reason not > to include it. And _that_ is the reason, why running ldconfig would not add any value in this case. From jwboyer at jdub.homelinux.org Sat Jul 16 15:06:16 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 16 Jul 2005 10:06:16 -0500 Subject: Bugzilla usage In-Reply-To: <20050716143010.GA6698@jadzia.bu.edu> References: <1121428259.2685.45.camel@yoda.jdub.homelinux.org> <1121478955.3128.59.camel@localhost> <1121519127.2685.50.camel@yoda.jdub.homelinux.org> <20050716143010.GA6698@jadzia.bu.edu> Message-ID: <1121526376.2685.52.camel@yoda.jdub.homelinux.org> On Sat, 2005-07-16 at 10:30 -0400, Matthew Miller wrote: > On Sat, Jul 16, 2005 at 08:05:26AM -0500, Josh Boyer wrote: > > Or do the {CURRENT,NEXT}RELEASE resolutions indicate that the bug was > > fixed in the current release of Extras its self? > > Yeah, that. See > Ah, got it. ERRATA it is then. Thanks all. josh From ermeyers at adelphia.net Sat Jul 16 15:10:06 2005 From: ermeyers at adelphia.net (Eric R. Meyers) Date: Sat, 16 Jul 2005 11:10:06 -0400 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050716142225.9AB9073468@hormel.redhat.com> References: <20050716142225.9AB9073468@hormel.redhat.com> Message-ID: <200507161110.19356.ermeyers@adelphia.net> On Saturday 16 July 2005 10:22, Jeff Spaleta wrote: > yum --disablerepo=development groupinfo 'Engineering and Scientific' > ... > Core has a comps file and Extras as a seperate comps file. Yum > merges groups listed in both files. Jeff, Got it! Using your helpful info, I ran the following to see the core basis, and I saw only those mysterious core comps.xml items. yum --disablerepo=development --disablerepo=extras groupinfo 'Engineering and Scientific' It makes much more sense now. Thanks very much. Eric -- Eric R. Meyers Systems Engineer GPG: 0x83CE80A3 http://users.adelphia.net/~ermeyers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rms at 1407.org Sat Jul 16 17:33:56 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sat, 16 Jul 2005 18:33:56 +0100 Subject: Request for Review: nautilus-open-terminal Message-ID: <1121535236.2773.24.camel@roque> Hello, I've made a package for nautilus-open-terminal, it's posted at http://www.1407.org/files/20050716/nautilus-open-terminal-0.4-0.1.src.rpm http://www.1407.org/files/20050716/nautilus-open-terminal.spec And signed with my pgp key 0x7A34FADE AFAICT, there aren't any legal issues or licensing problems. What is nautilus-open-terminal? Well, in light of a recent monster-thread on fedora-devel-list, I've decided to do something about it, specially since this was a relatively quick thing to do, and I packaged it for Extras: From the README: This is a proof-of-concept Nautilus extension which allows you to open a terminal in arbitrary local folders. I offer to maintain and follow upstream new releases on this package. Since I applied today, I still need a sponsor for Fedora Extras CVS access, and I even signed the CLA. Thanks, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 Sat Jul 16 18:42:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 16 Jul 2005 13:42:32 -0500 Subject: Request for Review: nautilus-open-terminal In-Reply-To: <1121535236.2773.24.camel@roque> References: <1121535236.2773.24.camel@roque> Message-ID: <1121539352.2755.128.camel@localhost.localdomain> On Sat, 2005-07-16 at 18:33 +0100, Rui Miguel Seabra wrote: > Hello, > > I've made a package for nautilus-open-terminal, it's posted at This one's already been taken by Paul Frields. Paul, your package is approved. Please go ahead and get it into cvs. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Sat Jul 16 18:52:58 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 16 Jul 2005 13:52:58 -0500 Subject: [Fedora-packaging] Re: Using %{dist} for conditional compilation In-Reply-To: <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> References: <42D82113.5030005@cora.nwra.com> <1121466537.2665.41.camel@locolhost.localdomain> <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> Message-ID: <1121539978.2755.131.camel@localhost.localdomain> On Sat, 2005-07-16 at 11:47 -0700, Kenneth Porter wrote: > --On Friday, July 15, 2005 3:28 PM -0700 "Michael A. Peters" > wrote: > > > different spec files in the different branches seems best to me. > > OTOH, if your objective is to create a tarball that can also be built as an > RPM, then you want a single spec file so that -ta is unambiguous. The dist tag guidelines are setup specifically so that you can either use them, or not use them. If you don't like the idea of using them in your packages, by all means, do not. It will NOT fail a review if you don't use them. However, if you want to use them, all you have to do is use them properly. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Sat Jul 16 23:04:12 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 16 Jul 2005 19:04:12 -0400 Subject: Request for review: pygame Message-ID: <1121555052.12397.1.camel@ignacio.lan> pygame: A set of Python modules designed for writing games Pygame is a set of Python modules designed for writing games. It is written on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the python language. http://fedora.ivazquez.net/files/extras/pygame.spec http://fedora.ivazquez.net/files/extras/pygame-1.6.2-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 bugs.michael at gmx.net Sat Jul 16 23:20:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 17 Jul 2005 01:20:22 +0200 Subject: ots Message-ID: <20050717012022.60ffd702.bugs.michael@gmx.net> Package "ots" is maintained by whom? From bugs.michael at gmx.net Sat Jul 16 23:22:13 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 17 Jul 2005 01:22:13 +0200 Subject: p0f Message-ID: <20050717012213.30161685.bugs.michael@gmx.net> Package "p0f" is maintained by whom? From mpeters at mac.com Sun Jul 17 00:55:52 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 16 Jul 2005 17:55:52 -0700 Subject: [Fedora-packaging] Re: Using %{dist} for conditional compilation In-Reply-To: <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> References: <42D82113.5030005@cora.nwra.com> <1121466537.2665.41.camel@locolhost.localdomain> <0D1A01AC7FC43BAC0C7532DB@[10.0.0.14]> Message-ID: <1121561752.2665.62.camel@locolhost.localdomain> On Sat, 2005-07-16 at 11:47 -0700, Kenneth Porter wrote: > --On Friday, July 15, 2005 3:28 PM -0700 "Michael A. Peters" > wrote: > > > different spec files in the different branches seems best to me. > > OTOH, if your objective is to create a tarball that can also be built as an > RPM, then you want a single spec file so that -ta is unambiguous. spec files in upstream tarballs should really try to avoid using distribution specific macros anyway. From joelwreed at comcast.net Sun Jul 17 02:43:43 2005 From: joelwreed at comcast.net (joel reed) Date: Sat, 16 Jul 2005 22:43:43 -0400 Subject: Request for review (round2): libxslt-plugin-regexp and libxslt-plugin-dates-and-time Message-ID: <20050717024343.GB2368@comcast.net> I posted a request for review on July 8th, and received helpful feedback from Ignacio Vazquez-Abrams. I believe I've addressed all the original concerns and also get clean rpmlint runs on the binary rpms now. If the specs/rpms look good now, I believe the next step is to import the src.rpm into Fedora Extra's CVS. I've applied for a new account in Fedora Extra CVS. Daniel, is now an appropriate time to review my CVS committer application? The updated spec/rpm files can be found here: http://home.comcast.net/~joelwreed/libxslt-plugin-regexp-0.5-1.src.rpm http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times-0.2-1.src.rpm http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times.spec As a reminder, the following two libxslt plugins add support for a few http://exslt.org extension functions. 1. regular-expressions Implements regexp:test, regexp.match, and regexp:replace using PCRE. 2. dates-and-times Implements format:date using libgcj. jr From rc040203 at freenet.de Sun Jul 17 05:38:29 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 17 Jul 2005 07:38:29 +0200 Subject: Request for review: libgeotiff In-Reply-To: References: Message-ID: <1121578709.4468.23.camel@mccallum.corsepiu.local> On Fri, 2005-07-15 at 21:38 -0700, Shawn McCann wrote: > As part of an effort to add some GIS tools to extras (namely Quantum GIS and > GRASS), I've packaged up libgeotiff for extras: > > SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec > SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm This spec is not ready for inclusion. * Blockers: - Installation to /usr/local (Use %configure instead of ./configure). - Permissions on many installed files are wrong (E.g. executable headers, executable static libs, executable data files). - Package does not acknowledge RPM_OPT_FLAGS (Use %configure instead of ./configure) - Shared libraries are packaged incorrectly (lib*.so belongs into *devel, lib*.so.* into non-devel). - The "Provides:" line is wrong. * Non-blockers: - Headers are installed to $(includedir), which means they pollute the system header namespace. I'd recommend to install the headers into a subdir of $(includedir) (i.e. %configure --includedir= %{_includedir}/geotiff or similar). - I recommend not to ship static libs (lib*.a) Ralf From kevacm at gmail.com Sun Jul 17 06:07:54 2005 From: kevacm at gmail.com (Kevac Marko) Date: Sun, 17 Jul 2005 10:07:54 +0400 Subject: djvulibre for fc4 x86_64 Message-ID: <42D9F5BA.2030200@gmail.com> Hello. Have somebody already build djvulibre for fc4 x86_64? Kevac Marko Moscow, Russia From ivazquez at ivazquez.net Sun Jul 17 07:19:28 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 17 Jul 2005 03:19:28 -0400 Subject: Request for review (round2): libxslt-plugin-regexp and libxslt-plugin-dates-and-time In-Reply-To: <20050717024343.GB2368@comcast.net> References: <20050717024343.GB2368@comcast.net> Message-ID: <1121584769.12397.10.camel@ignacio.lan> On Sat, 2005-07-16 at 22:43 -0400, joel reed wrote: > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp-0.5-1.src.rpm > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec - Build in mock failed due to missing BR of pcre-devel - %{_libdir}/libxslt is unowned - Odd spacing in %install and %files ? Are you sure the minimum versions of libxml2 and libxslt are accurate? > http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times-0.2-1.src.rpm > http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times.spec + Build in mock succeeded - %{_libdir}/libxslt is unowned - Odd spacing in %install and %files - Explicit Requires of libgcj should be dropped ? Are you sure the minimum versions of libxml2 and libxslt are accurate? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 symbiont at berlios.de Sun Jul 17 08:13:35 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 17 Jul 2005 16:13:35 +0800 Subject: %{?dist} (was: Re: Request for a sponsor and a review of: pam_abl) In-Reply-To: <20050715103235.7f9dc6ed.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <200507151441.37542.symbiont@berlios.de> <20050715103235.7f9dc6ed.bugs.michael@gmx.net> Message-ID: <200507171613.35512.symbiont@berlios.de> On Friday 15 July 2005 16:32, Michael Schwendt wrote: > Btw, you've still not given a good reason why you want to enforce > %{?dist} on packagers. Where is the value in making it mandatory? Never said that it should be mandatory. I just don't want it to be mandatory that noarch packages cannot have dist. That's it! I was just being facetious in my last email about the upgrade-path safety. -- -jeff From rc040203 at freenet.de Sun Jul 17 08:23:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 17 Jul 2005 10:23:26 +0200 Subject: %{?dist} (was: Re: Request for a sponsor and a review of: pam_abl) In-Reply-To: <200507171613.35512.symbiont@berlios.de> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <200507151441.37542.symbiont@berlios.de> <20050715103235.7f9dc6ed.bugs.michael@gmx.net> <200507171613.35512.symbiont@berlios.de> Message-ID: <1121588606.4468.62.camel@mccallum.corsepiu.local> On Sun, 2005-07-17 at 16:13 +0800, Jeff Pitman wrote: > On Friday 15 July 2005 16:32, Michael Schwendt wrote: > > Btw, you've still not given a good reason why you want to enforce > > %{?dist} on packagers. Where is the value in making it mandatory? > > Never said that it should be mandatory. I just don't want it to be > mandatory that noarch packages cannot have dist. That's it! Making not using %{?dist} for noarch package mandatory would be equally wrong, because noarch package may also depend on distribution specific features (e.g. the perl, python directories, other install dirs of other files (cf. to the /usr/man vs. /usr/share/man switch, long ago) or on presence/non-presence of certain other packages (e.g. perl modules sometimes change their dependencies or built-time optional features might be added/removed to a fedora release). Ralf From ghaefbgtk at gmail.com Sun Jul 17 10:10:06 2005 From: ghaefbgtk at gmail.com (Nil Gradisnik) Date: Sun, 17 Jul 2005 12:10:06 +0200 Subject: Sysinfo to fedora extras Message-ID: I'd like to add my project Sysinfo 0.6 to Fedora Extras. You can find more details on project page: http://sysinfo.r8.org I have attached the src.rpm and I build an rpm myself. What do I need to do next ? Thanks From ghaefbgtk at gmail.com Sun Jul 17 10:10:55 2005 From: ghaefbgtk at gmail.com (Nil Gradisnik) Date: Sun, 17 Jul 2005 12:10:55 +0200 Subject: Sysinfo to fedora extras In-Reply-To: References: Message-ID: Forgot to attach sr.rpm file. Sorry On 7/17/05, Nil Gradisnik wrote: > I'd like to add my project Sysinfo 0.6 to Fedora Extras. > You can find more details on project page: http://sysinfo.r8.org > > I have attached the src.rpm and I build an rpm myself. > What do I need to do next ? > > Thanks > -------------- next part -------------- A non-text attachment was scrubbed... Name: sysinfo-0.6-1.src.rpm Type: application/x-rpm Size: 1912 bytes Desc: not available URL: From mfleming at enlartenment.com Sun Jul 17 10:36:29 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sun, 17 Jul 2005 20:36:29 +1000 Subject: Sysinfo to fedora extras In-Reply-To: References: Message-ID: <20050717203629.1748613a.mfleming@enlartenment.com> On Sun, 17 Jul 2005 12:10:55 +0200. Nil Gradisnik waffled thusly: > Forgot to attach sr.rpm file. > Sorry (Please don't top post!) No need to send the RPM, just the .spec or (even better) a link to the spec + source / binary RPMS. BTW, I packaged this myself today for my own repo, it's a small and quite useful little app: http://www.enlartenment.com/packages/fedora/4/i386/repodata/repoview/sysinfo-0-0.6-2.fc4.mf.html http://www.enlartenment.com/packages/fedora/4/SRPMS/sysinfo-0.6-2.fc4.mf.src.rpm (SRPM) > On 7/17/05, Nil Gradisnik wrote: > > I'd like to add my project Sysinfo 0.6 to Fedora Extras. > > You can find more details on project page: http://sysinfo.r8.org > > > > I have attached the src.rpm and I build an rpm myself. > > What do I need to do next ? See http://www.fedoraproject.org/wiki/NewPackageProcess for an outline on the package submission process. I've looked over the spec and it needs some serious love before it's up to Extras quality. At present I don't believe it will build. - Spec filename should not refer to the version. - No Source: line! - Don't hardcode the Packager or Vendor. - No BuildRequires (needed desktop-file-utils libglademm24-devel and libgtkmm24-devel for my package) - Group not listed in rpm's GROUPS list (I used Applications/System FWIW) - No %configure? - No need to CD to the build dir manually, the build will do this automagically. - No DESTDIR or similar in %install - the "make install" command will try and install to the live system - this will a) prevent non-root builds and b) pollute the system proper (if not built in a chroot jail). Use "make DESTDIR= %{buildroot} install". - Good idea to rm -rf %{buildroot} before doing a "make DESTDIR=%{buildroot} install" - this will ensure no stale data exists from previous builds. - Use the %{_foo} macros if available, in both the build process and %files. - no %changelog - no URL: - Feel free to make the %description more verbose - use %doc instead of specifying /usr/doc/sysinfo/* in %files. Are you also aware that some of the docs are in fact symlinks to their equivalents in the "automake-1.9" package? This should be fixed in the main tarball. You might want to look over http://www.fedoraproject.org/wiki/PackagingGuidelines for ideas on what is expected for Extras inclusion. The "rpmlint" and "fedora-rpmdevtools" packages (part of Extras) are also invaluable. Feel free to look over my SRPM and spec also. > > > > Thanks > > Cheers, Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From rms at 1407.org Sun Jul 17 10:45:06 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 11:45:06 +0100 Subject: Ownership claim: MagicPoint Message-ID: <1121597106.18089.18.camel@roque> Hi, I sadly saw that MagicPoint is orphaned. I'd like to claim "ownership" of the package. I've rebuilt myself the rpm based on the last src.rpm by Red Hat, and fiddled a little with it so it would work better than it did previously (including more detail in the BuildRequires section). The src.rpm and spec are at http://www.1407.org/files/20050717/ All bugs in bugzilla are closed (btw, my email is my account there). Regards, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 ville.skytta at iki.fi Sun Jul 17 10:53:15 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 17 Jul 2005 13:53:15 +0300 Subject: Request for review: pygame In-Reply-To: <1121555052.12397.1.camel@ignacio.lan> References: <1121555052.12397.1.camel@ignacio.lan> Message-ID: <1121597595.2872.276.camel@localhost.localdomain> On Sat, 2005-07-16 at 19:04 -0400, Ignacio Vazquez-Abrams wrote: > pygame: A set of Python modules designed for writing games This was already discussed here a while back; without MPEG support (from smpeg), pygame is more or less crippled. There's a "full featured" one already available from rpm.livna.org (as python-pygame). Whether it makes sense to ship a less featured one in Extras, dunno about this specific case. In general I don't think so. If you disagree, this package could use some work: - Missing BuildRequires: python-devel - Unnecessary explicit Requires: SDL_* - Missing dependencies in -devel: SDL-devel, SDL_ttf-devel, SDL_mixer-devel, python-devel (For the following three, see eg. the rpm.livna.org specfile) - Could use config.py for configuring instead of shipping a hardcoded "Setup" (with h/c'd "/usr/lib" and "python2.4" paths etc) - Could perhaps run the test suite in %check - Could ship the docs in a separate "-doc" subpackage, and add examples to it From fedora at leemhuis.info Sun Jul 17 11:04:57 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 17 Jul 2005 13:04:57 +0200 Subject: Request for review: pygame In-Reply-To: <1121555052.12397.1.camel@ignacio.lan> References: <1121555052.12397.1.camel@ignacio.lan> Message-ID: <1121598297.3368.10.camel@localhost.localdomain> Am Samstag, den 16.07.2005, 19:04 -0400 schrieb Ignacio Vazquez-Abrams: > pygame: A set of Python modules designed for writing games > > Pygame is a set of Python modules designed for writing games. It is > written on top of the excellent SDL library. This allows you to create > fully featured games and multimedia programs in the python language. > > http://fedora.ivazquez.net/files/extras/pygame.spec > http://fedora.ivazquez.net/files/extras/pygame-1.6.2-1.src.rpm Fyi: There is a pygame in livna already (it's named python-pygame there). Other 3rd-party repos seem to have it also. In livna it's build against smpeg-devel, other repos probably do the same. That leads to the question: Does a majority of the games based on pygame require it with mpeg-support? If yes it *might* be better to just leave pygame out of extras and let the 3rd-party repos do their job. Or has pygame plugin-support or something like that so this problem could be solved easily? -- Thorsten Leemhuis From ville.skytta at iki.fi Sun Jul 17 11:39:44 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 17 Jul 2005 14:39:44 +0300 Subject: Request for review: dvb-apps In-Reply-To: <1120137429.2815.100.camel@localhost.localdomain> References: <1120137429.2815.100.camel@localhost.localdomain> Message-ID: <1121600384.2872.298.camel@localhost.localdomain> On Thu, 2005-06-30 at 16:17 +0300, Ville Skytt? wrote: > http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps > > dvb-apps is a package containing utility, demo and test applications > using the Linux DVB API. > > The package is meant for FC4 and later, builds and works for me on i386, > build tested on ppc, x86_64 untested. > > http://cachalot.mine.nu/4/SRPMS/dvb-apps-1.1.0-0.4.src.rpm Anyone? This should be a pretty trivial review. From ed at eh3.com Sun Jul 17 14:10:16 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 17 Jul 2005 10:10:16 -0400 Subject: Request for Review: hdf In-Reply-To: <42D837C8.3000603@cora.nwra.com> References: <42D837C8.3000603@cora.nwra.com> Message-ID: <1121609416.13211.30.camel@ernie> Hi Orion, If someone else doesn't get to it first, I promise to review hdf next weekend (7/23--7/24). I'm just insanely busy right now! ;-) Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From tcallawa at redhat.com Sun Jul 17 15:47:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 17 Jul 2005 10:47:09 -0500 Subject: Request for review: dvb-apps In-Reply-To: <1121600384.2872.298.camel@localhost.localdomain> References: <1120137429.2815.100.camel@localhost.localdomain> <1121600384.2872.298.camel@localhost.localdomain> Message-ID: <1121615229.2755.144.camel@localhost.localdomain> On Sun, 2005-07-17 at 14:39 +0300, Ville Skytt? wrote: > On Thu, 2005-06-30 at 16:17 +0300, Ville Skytt? wrote: > > http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps > > > > dvb-apps is a package containing utility, demo and test applications > > using the Linux DVB API. > > > > The package is meant for FC4 and later, builds and works for me on i386, > > build tested on ppc, x86_64 untested. > > > > http://cachalot.mine.nu/4/SRPMS/dvb-apps-1.1.0-0.4.src.rpm > > Anyone? This should be a pretty trivial review. Review: Bad: - Missing COPYING (or some other file containing GPL) Good: - rpmlint clean - naming ok - package meets PackagingGuidelines - license OK (GPL), matches files... - spec is in Am. English, is legible - Sources match upstream - package compiles/builds on x86 (FC4) - no locales - no shared/static libs - not relocatable - owns all directories that it makes - no duplicate files in %files - permissions ok - clean section ok - macro use consistent - code, not content - no large docs - all %doc files ok (except missing GPL license text) Except for the one blocker, this looks great. Since its a trivial thing to fix (I'm confident in your ability to find that file and include it as Source1), this package is approved. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Sun Jul 17 16:31:16 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 17 Jul 2005 19:31:16 +0300 Subject: Request for review: dvb-apps In-Reply-To: <1121615229.2755.144.camel@localhost.localdomain> References: <1120137429.2815.100.camel@localhost.localdomain> <1121600384.2872.298.camel@localhost.localdomain> <1121615229.2755.144.camel@localhost.localdomain> Message-ID: <1121617876.2931.1.camel@localhost.localdomain> On Sun, 2005-07-17 at 10:47 -0500, Tom 'spot' Callaway wrote: > - Missing COPYING (or some other file containing GPL) [...] > Except for the one blocker, this looks great. Since its a trivial thing > to fix (I'm confident in your ability to find that file and include it > as Source1), this package is approved. Thanks, imported and COPYING included in a post-import update. From jspaleta at gmail.com Sun Jul 17 19:02:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 17 Jul 2005 15:02:09 -0400 Subject: Ownership claim: MagicPoint In-Reply-To: <1121597106.18089.18.camel@roque> References: <1121597106.18089.18.camel@roque> Message-ID: <604aa7910507171202e53891d@mail.gmail.com> On 7/17/05, Rui Miguel Seabra wrote: > The src.rpm and spec are at > > http://www.1407.org/files/20050717/ If you are using --disabling-vflib do you still need VFlib2-devel as a buildrequires? It appears that the binary you built doesn't end up requiring VFlib2. Your srpm rpm rebuilds in mock for fc4 but because of the VFlib2-devel requirement doesn't complete correctly for development under mock. VFlib2 is no longer available in core-development, so you'd need to prepare different specs or a conditional to handle both extras-fc4 and extras-development. If you can remove that VFlib2-devel completely that would probably be the least complicated solution. the run of rpmlint on my mock built rpm contains a few items covered in http://fedoraproject.org/wiki/PackagingGuidelines W: MagicPoint summary-ended-with-dot X based presentation software. easy fix just remove that period. E: MagicPoint obsolete-not-provided mgp E: MagicPoint obsolete-not-provided magicpoint You need to add a Provides for mgp and magicpoint W: MagicPoint incoherent-version-in-changelog 1.11b-1 1.11b-6 Make sure you add a changelog entry for each release bump you do. -jef From rms at 1407.org Sun Jul 17 19:14:37 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 20:14:37 +0100 Subject: Ownership claim: MagicPoint In-Reply-To: <604aa7910507171202e53891d@mail.gmail.com> References: <1121597106.18089.18.camel@roque> <604aa7910507171202e53891d@mail.gmail.com> Message-ID: <1121627677.2923.17.camel@roque> I expected issues would be found and that the package wouldn't respect the packaging guidelines, but I point out that I merely used Red Hat's spec, instead of following a fresh approach. Maybe I should make a new one based on the template and working my way over from it. What would you advise? I followed this procedure since it's not a new package, but I can just as easily change. Thanks, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 rms at 1407.org Sun Jul 17 19:41:55 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 20:41:55 +0100 Subject: Ownership claim: MagicPoint In-Reply-To: <604aa7910507171202e53891d@mail.gmail.com> References: <1121597106.18089.18.camel@roque> <604aa7910507171202e53891d@mail.gmail.com> Message-ID: <1121629315.2923.26.camel@roque> Anyways, a new version is uploaded with all these issues (and others) fixed. [builder at roque SPECS]$ rpmlint /home/builder/redhat/RPMS/i386/MagicPoint-1.11b-0.1.i386.rpm [builder at roque SPECS]$ echo $? 0 ... at http://www.1407.org/files/20050717/ Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 byte at aeon.com.my Sun Jul 17 20:11:40 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 17 Jul 2005 16:11:40 -0400 Subject: Ownership claim: MagicPoint In-Reply-To: <1121597106.18089.18.camel@roque> References: <1121597106.18089.18.camel@roque> Message-ID: <1121631100.3299.335.camel@potter.soho.bytebot.net> On Sun, 2005-07-17 at 11:45 +0100, Rui Miguel Seabra wrote: > I sadly saw that MagicPoint is orphaned. I'd like to claim > "ownership" > of the package. I own the package! It has clearly failed to build in mock (on the buildsys) each time I submit it, but that was during the recent buildsys hiatus. Let me resubmit a request for a build -- Colin Charles, http://www.bytebot.net/ From rms at 1407.org Sun Jul 17 20:17:50 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 21:17:50 +0100 Subject: Ownership claim: MagicPoint In-Reply-To: <1121631100.3299.335.camel@potter.soho.bytebot.net> References: <1121597106.18089.18.camel@roque> <1121631100.3299.335.camel@potter.soho.bytebot.net> Message-ID: <1121631470.2923.28.camel@roque> On Sun, 2005-07-17 at 16:11 -0400, Colin Charles wrote: > On Sun, 2005-07-17 at 11:45 +0100, Rui Miguel Seabra wrote: > > I sadly saw that MagicPoint is orphaned. I'd like to claim > > "ownership" > > of the package. > > I own the package! > > It has clearly failed to build in mock (on the buildsys) each time I > submit it, but that was during the recent buildsys hiatus. Let me > resubmit a request for a build Please, check if you have time for that, it's orphaned for quite some time, it seems. Also, make sure you pick on the spec I've worked at, it's cleaner, and mgp is working fine over here. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 smccann at canasoft.ca Sun Jul 17 20:20:26 2005 From: smccann at canasoft.ca (Shawn McCann) Date: Sun, 17 Jul 2005 13:20:26 -0700 (PDT) Subject: Request for review: libgeotiff In-Reply-To: <1121578709.4468.23.camel@mccallum.corsepiu.local> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> Message-ID: <40120.172.16.100.62.1121631626.squirrel@ubuntu> Ralf, Thanks for the feedback. I've updated the file to address all your comments and posted the new version. SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm However, I'm having one problem now. The base package includes two executables that link to libgeotiff.so (which is why I had libgeotiff.so in the base package and included it in the Provides: directive). Now that I've moved libgeotiff.so back to the devel package, the base package won't install as it can't find libgeotiff.so. Any advice on how to deal with this? Thanks Shawn > On Fri, 2005-07-15 at 21:38 -0700, Shawn McCann wrote: >> As part of an effort to add some GIS tools to extras (namely Quantum GIS >> and >> GRASS), I've packaged up libgeotiff for extras: >> >> SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec >> SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm > > This spec is not ready for inclusion. > > * Blockers: > - Installation to /usr/local (Use %configure instead of ./configure). > - Permissions on many installed files are wrong (E.g. executable > headers, executable static libs, executable data files). > - Package does not acknowledge RPM_OPT_FLAGS (Use %configure instead > of ./configure) > - Shared libraries are packaged incorrectly (lib*.so belongs into > *devel, lib*.so.* into non-devel). > - The "Provides:" line is wrong. > > * Non-blockers: > - Headers are installed to $(includedir), which means they pollute the > system header namespace. I'd recommend to install the headers into a > subdir of $(includedir) (i.e. %configure --includedir= > %{_includedir}/geotiff or similar). > - I recommend not to ship static libs (lib*.a) > > Ralf > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From rms at 1407.org Sun Jul 17 20:25:12 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 21:25:12 +0100 Subject: ots In-Reply-To: <20050717012022.60ffd702.bugs.michael@gmx.net> References: <20050717012022.60ffd702.bugs.michael@gmx.net> Message-ID: <1121631912.2923.29.camel@roque> On Sun, 2005-07-17 at 01:20 +0200, Michael Schwendt wrote: > Package "ots" is maintained by whom? If nobody else, I can inherit it. In the original ots.spec (from my cvs copy): %changelog * Thu Jun 05 2003 Rui Miguel Silva Seabra - fix spec - disable gtk-doc (it's not building in RH 9, maybe it's broken for some reason) * Fri May 02 2003 Rui Miguel Silva Seabra - define a longer description from the README file - explicitly set file permissions Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 joelwreed at comcast.net Sun Jul 17 20:30:07 2005 From: joelwreed at comcast.net (joel reed) Date: Sun, 17 Jul 2005 16:30:07 -0400 Subject: Request for review (round2): libxslt-plugin-regexp and libxslt-plugin-dates-and-time In-Reply-To: <1121584769.12397.10.camel@ignacio.lan> References: <20050717024343.GB2368@comcast.net> <1121584769.12397.10.camel@ignacio.lan> Message-ID: <20050717203007.GA26432@comcast.net> On Sun, Jul 17, 2005 at 03:19:28AM -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-07-16 at 22:43 -0400, joel reed wrote: > > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp-0.5-1.src.rpm > > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec > > - Build in mock failed due to missing BR of pcre-devel > - %{_libdir}/libxslt is unowned can you tell me how to "own" this directory? the rpm must put the files here for libxslt to automatically load them. thanks. > - Odd spacing in %install and %files could you be more specific? i'm not trying to be dense, but i don't see whats odd about the spacing... > ? Are you sure the minimum versions of libxml2 and libxslt are accurate? the minimums reflect what i tested against. an earlier version or two may work, but i didn't want to put something in there i could not test. thanks for your clarifications! jr From rms at 1407.org Sun Jul 17 20:34:53 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 21:34:53 +0100 Subject: Request for review (round2): libxslt-plugin-regexp and libxslt-plugin-dates-and-time In-Reply-To: <20050717203007.GA26432@comcast.net> References: <20050717024343.GB2368@comcast.net> <1121584769.12397.10.camel@ignacio.lan> <20050717203007.GA26432@comcast.net> Message-ID: <1121632493.2923.32.camel@roque> On Sun, 2005-07-17 at 16:30 -0400, joel reed wrote: > On Sun, Jul 17, 2005 at 03:19:28AM -0400, Ignacio Vazquez-Abrams wrote: > > On Sat, 2005-07-16 at 22:43 -0400, joel reed wrote: > > > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp-0.5-1.src.rpm > > > http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec > > > > - Build in mock failed due to missing BR of pcre-devel > > - %{_libdir}/libxslt is unowned > > can you tell me how to "own" this directory? the rpm must put > the files here for libxslt to automatically load them. thanks. %dir ... > > - Odd spacing in %install and %files > > could you be more specific? i'm not trying to be dense, but i don't > see whats odd about the spacing... The blank lines between some elements. Remove them and you should be scott-free > > ? Are you sure the minimum versions of libxml2 and libxslt are accurate? > > the minimums reflect what i tested against. an earlier version or two > may work, but i didn't want to put something in there i could not test. Maybe starting by not specifying a version until someone complains? Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 bugs.michael at gmx.net Sun Jul 17 20:49:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 17 Jul 2005 22:49:39 +0200 Subject: Request for review: libgeotiff In-Reply-To: <40120.172.16.100.62.1121631626.squirrel@ubuntu> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> <40120.172.16.100.62.1121631626.squirrel@ubuntu> Message-ID: <20050717224939.4f43b735.bugs.michael@gmx.net> On Sun, 17 Jul 2005 13:20:26 -0700 (PDT), Shawn McCann wrote: > Ralf, > > Thanks for the feedback. I've updated the file to address all your > comments and posted the new version. > > SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec > SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm > > However, I'm having one problem now. The base package includes two > executables that link to libgeotiff.so (which is why I had libgeotiff.so > in the base package and included it in the Provides: directive). Now that > I've moved libgeotiff.so back to the devel package, the base package won't > install as it can't find libgeotiff.so. Any advice on how to deal with > this? That's upstream sloppiness -- a bug. Library has no SONAME. It ought to be patched to get the name "libgeotiff.so.1". Then the executables will link against and depend on the proper SONAME. You also want to include the following directories in the binary packages: /usr/include/geotiff/ /usr/share/epsg_csv/ Some of Ralf's findings are not fixed yet. From byte at aeon.com.my Sun Jul 17 20:50:23 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 17 Jul 2005 16:50:23 -0400 Subject: Ownership claim: MagicPoint In-Reply-To: <1121631470.2923.28.camel@roque> References: <1121597106.18089.18.camel@roque> <1121631100.3299.335.camel@potter.soho.bytebot.net> <1121631470.2923.28.camel@roque> Message-ID: <1121633423.3299.343.camel@potter.soho.bytebot.net> On Sun, 2005-07-17 at 21:17 +0100, Rui Miguel Seabra wrote: > > It has clearly failed to build in mock (on the buildsys) each time I > > submit it, but that was during the recent buildsys hiatus. Let me > > resubmit a request for a build > > Please, check if you have time for that, it's orphaned for quite some > time, it seems. Where are you getting this orphaned list from? I can't seem to find it on the wiki > Also, make sure you pick on the spec I've worked at, it's cleaner, and > mgp is working fine over here. I will, eventually, I want the first cut (i.e. what was from Core) to get built first thru the buildsystem. After that, I'll take a gander at your spec. -- Colin Charles, http://www.bytebot.net/ From rms at 1407.org Sun Jul 17 20:57:55 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 17 Jul 2005 21:57:55 +0100 Subject: Ownership claim: MagicPoint In-Reply-To: <1121633423.3299.343.camel@potter.soho.bytebot.net> References: <1121597106.18089.18.camel@roque> <1121631100.3299.335.camel@potter.soho.bytebot.net> <1121631470.2923.28.camel@roque> <1121633423.3299.343.camel@potter.soho.bytebot.net> Message-ID: <1121633875.2923.38.camel@roque> On Sun, 2005-07-17 at 16:50 -0400, Colin Charles wrote: > On Sun, 2005-07-17 at 21:17 +0100, Rui Miguel Seabra wrote: > > > > It has clearly failed to build in mock (on the buildsys) each time I > > > submit it, but that was during the recent buildsys hiatus. Let me > > > resubmit a request for a build > > > > Please, check if you have time for that, it's orphaned for quite some > > time, it seems. > > Where are you getting this orphaned list from? I can't seem to find it > on the wiki http://fedoraproject.org/wiki/Extras/OrphanedPackages > > Also, make sure you pick on the spec I've worked at, it's cleaner, and > > mgp is working fine over here. > > I will, eventually, I want the first cut (i.e. what was from Core) to > get built first thru the buildsystem. After that, I'll take a gander at > your spec. Please do, fonts looked better with my RPMS than with the original ones... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 byte at aeon.com.my Sun Jul 17 21:02:50 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 17 Jul 2005 17:02:50 -0400 Subject: Ownership claim: MagicPoint In-Reply-To: <1121633875.2923.38.camel@roque> References: <1121597106.18089.18.camel@roque> <1121631100.3299.335.camel@potter.soho.bytebot.net> <1121631470.2923.28.camel@roque> <1121633423.3299.343.camel@potter.soho.bytebot.net> <1121633875.2923.38.camel@roque> Message-ID: <1121634170.3299.348.camel@potter.soho.bytebot.net> On Sun, 2005-07-17 at 21:57 +0100, Rui Miguel Seabra wrote: > > > > It has clearly failed to build in mock (on the buildsys) each time I > > > > submit it, but that was during the recent buildsys hiatus. Let me > > > > resubmit a request for a build > > > > > > Please, check if you have time for that, it's orphaned for quite some > > > time, it seems. > > > > Where are you getting this orphaned list from? I can't seem to find it > > on the wiki > > http://fedoraproject.org/wiki/Extras/OrphanedPackages Mea culpa, didn't remove it from the list when checking it in (as per post to fedora-extras-list). And when I checked the list, mschwendt had already gotten to it to remove MagicPoint ;-) > > I will, eventually, I want the first cut (i.e. what was from Core) to > > get built first thru the buildsystem. After that, I'll take a gander at > > your spec. > > Please do, fonts looked better with my RPMS than with the original > ones... /me awaits an FC-4 build now -- Colin Charles, http://www.bytebot.net/ From tcallawa at redhat.com Sun Jul 17 21:54:44 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 17 Jul 2005 16:54:44 -0500 Subject: Ownership claim: MagicPoint In-Reply-To: <1121627677.2923.17.camel@roque> References: <1121597106.18089.18.camel@roque> <604aa7910507171202e53891d@mail.gmail.com> <1121627677.2923.17.camel@roque> Message-ID: <1121637284.2755.151.camel@localhost.localdomain> On Sun, 2005-07-17 at 20:14 +0100, Rui Miguel Seabra wrote: > I expected issues would be found and that the package wouldn't respect > the packaging guidelines, but I point out that I merely used Red Hat's > spec, instead of following a fresh approach. Maybe I should make a new > one based on the template and working my way over from it. Umm, do as we say, not as we did? :) Red Hat is as guilty as anyone of having bad packages in the past. We're not using that as an excuse to keep doing it badly. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From smccann at canasoft.ca Mon Jul 18 00:05:22 2005 From: smccann at canasoft.ca (Shawn McCann) Date: Sun, 17 Jul 2005 17:05:22 -0700 (PDT) Subject: Request for review: libgeotiff In-Reply-To: <20050717224939.4f43b735.bugs.michael@gmx.net> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> <40120.172.16.100.62.1121631626.squirrel@ubuntu> <20050717224939.4f43b735.bugs.michael@gmx.net> Message-ID: <35161.172.16.100.62.1121645122.squirrel@ubuntu> OK, found a Makefile patch for this problem on newrpms.sunsite.dk (thanks to Rudolf Kastl) and have included it in the revised spec file. Both RPM packages install successfully now. Regarding the second comment, not sure why you think those files are not being included in the RPMS. /usr/share/epsg_csv is included under %files %{_datadir}/epsg_csv/*.csv /usr/include/geotiff is included under %files devel %{_includedir}/geotiff/*.h I checked the RPMs and the files are there. Shawn > On Sun, 17 Jul 2005 13:20:26 -0700 (PDT), Shawn McCann wrote: > >> Ralf, >> >> Thanks for the feedback. I've updated the file to address all your >> comments and posted the new version. >> >> SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec >> SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm >> >> However, I'm having one problem now. The base package includes two >> executables that link to libgeotiff.so (which is why I had libgeotiff.so >> in the base package and included it in the Provides: directive). Now >> that >> I've moved libgeotiff.so back to the devel package, the base package >> won't >> install as it can't find libgeotiff.so. Any advice on how to deal with >> this? > > That's upstream sloppiness -- a bug. Library has no SONAME. It ought > to be patched to get the name "libgeotiff.so.1". Then the executables > will link against and depend on the proper SONAME. > > You also want to include the following directories in the binary packages: > > /usr/include/geotiff/ > /usr/share/epsg_csv/ > > Some of Ralf's findings are not fixed yet. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From wtogami at redhat.com Mon Jul 18 00:57:33 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Jul 2005 14:57:33 -1000 Subject: Ownership claim: MagicPoint In-Reply-To: <1121627677.2923.17.camel@roque> References: <1121597106.18089.18.camel@roque> <604aa7910507171202e53891d@mail.gmail.com> <1121627677.2923.17.camel@roque> Message-ID: <42DAFE7D.5080608@redhat.com> Rui Miguel Seabra wrote: > I expected issues would be found and that the package wouldn't respect > the packaging guidelines, but I point out that I merely used Red Hat's > spec, instead of following a fresh approach. Maybe I should make a new > one based on the template and working my way over from it. > Many of Red Hat's packages in the past were poorly made, especially from a reproducibility standpoint. The Fedora Extras packaging standards encourage the improvement of packages across the board, and this has been slowly seeping into Core over the past 2 years. Pointing to a Red Hat is not an excuse not to read and follow the rules. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Mon Jul 18 05:01:14 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 18 Jul 2005 07:01:14 +0200 Subject: Request for review: libgeotiff In-Reply-To: <35161.172.16.100.62.1121645122.squirrel@ubuntu> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> <40120.172.16.100.62.1121631626.squirrel@ubuntu> <20050717224939.4f43b735.bugs.michael@gmx.net> <35161.172.16.100.62.1121645122.squirrel@ubuntu> Message-ID: <1121662875.4383.28.camel@mccallum.corsepiu.local> On Sun, 2005-07-17 at 17:05 -0700, Shawn McCann wrote: > OK, found a Makefile patch for this problem on newrpms.sunsite.dk (thanks > to Rudolf Kastl) and have included it in the revised spec file. Both RPM > packages install successfully now. > > Regarding the second comment, not sure why you think those files are not > being included in the RPMS. > > /usr/share/epsg_csv is included under %files > %{_datadir}/epsg_csv/*.csv > > /usr/include/geotiff is included under %files devel > %{_includedir}/geotiff/*.h The directories %{_datadir}/epsg_csv %{_includedir}/geotiff are unowned. You probably want to use %{_datadir}/epsg_csv %{_includedir}/geotiff > > On Sun, 17 Jul 2005 13:20:26 -0700 (PDT), Shawn McCann wrote: > > > >> Ralf, > >> > >> Thanks for the feedback. I've updated the file to address all your > >> comments and posted the new version. > >> > >> SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec > >> SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm > >> > >> However, I'm having one problem now. The base package includes two > >> executables that link to libgeotiff.so (which is why I had libgeotiff.so > >> in the base package and included it in the Provides: directive). Now > >> that > >> I've moved libgeotiff.so back to the devel package, the base package > >> won't > >> install as it can't find libgeotiff.so. Any advice on how to deal with > >> this? > > > > That's upstream sloppiness -- a bug. Library has no SONAME. It ought > > to be patched to get the name "libgeotiff.so.1". Then the executables > > will link against and depend on the proper SONAME. The patch sets SONAME to libgeotiff.so.1.2.2, i.e. binaries are being dynamically linked against libgeotiff.so.1.2.2: ldd /usr/bin/geotifcp ... libgeotiff.so.1.2.2 => /usr/lib/libgeotiff.so.1.2.2 (0x007ce000) The SONAME should better be libgeotiff.so.1 > > You also want to include the following directories in the binary packages: > > > > /usr/include/geotiff/ > > /usr/share/epsg_csv/ Exactly. This is not yet fixed yet. > > Some of Ralf's findings are not fixed yet. The bogus Provides: line is still present. I am proposing the patch to libgeotiff.spec and to the Makefile, below. An issue I haven't looked into: libgeotiff.so.1.2.2 contains references to other libraries (e.g. libtiff). So it could be reasonable to let the *-devel package require further *-devel packages (e.g. libtiff-devel). Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: libgeotiff.spec.diff Type: text/x-patch Size: 1012 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libgeotiff-1.2.2-Makefile.patch Type: text/x-patch Size: 407 bytes Desc: not available URL: From smccann at canasoft.ca Mon Jul 18 05:59:35 2005 From: smccann at canasoft.ca (Shawn McCann) Date: Sun, 17 Jul 2005 22:59:35 -0700 (PDT) Subject: Request for review: libgeotiff In-Reply-To: <1121662875.4383.28.camel@mccallum.corsepiu.local> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> <40120.172.16.100.62.1121631626.squirrel@ubuntu> <20050717224939.4f43b735.bugs.michael@gmx.net> <35161.172.16.100.62.1121645122.squirrel@ubuntu> <1121662875.4383.28.camel@mccallum.corsepiu.local> Message-ID: <44048.172.16.100.62.1121666375.squirrel@ubuntu> Ralf, Thanks for the detailed comments and for taking the time to provide the diffs. They were much easier for me to follow (I understand the comments about the directories now). I've updated the spec file as you've recommended and changed the Makefile patch to the one provided. Updated files are in the same place. SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm Shawn > On Sun, 2005-07-17 at 17:05 -0700, Shawn McCann wrote: >> OK, found a Makefile patch for this problem on newrpms.sunsite.dk >> (thanks >> to Rudolf Kastl) and have included it in the revised spec file. Both RPM >> packages install successfully now. >> >> Regarding the second comment, not sure why you think those files are not >> being included in the RPMS. >> >> /usr/share/epsg_csv is included under %files >> %{_datadir}/epsg_csv/*.csv >> >> /usr/include/geotiff is included under %files devel >> %{_includedir}/geotiff/*.h > > The directories %{_datadir}/epsg_csv %{_includedir}/geotiff are > unowned. > > You probably want to use > %{_datadir}/epsg_csv > %{_includedir}/geotiff > >> > On Sun, 17 Jul 2005 13:20:26 -0700 (PDT), Shawn McCann wrote: >> > >> >> Ralf, >> >> >> >> Thanks for the feedback. I've updated the file to address all your >> >> comments and posted the new version. >> >> >> >> SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec >> >> SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm >> >> >> >> However, I'm having one problem now. The base package includes two >> >> executables that link to libgeotiff.so (which is why I had >> libgeotiff.so >> >> in the base package and included it in the Provides: directive). Now >> >> that >> >> I've moved libgeotiff.so back to the devel package, the base package >> >> won't >> >> install as it can't find libgeotiff.so. Any advice on how to deal >> with >> >> this? >> > >> > That's upstream sloppiness -- a bug. Library has no SONAME. It ought >> > to be patched to get the name "libgeotiff.so.1". Then the executables >> > will link against and depend on the proper SONAME. > The patch sets SONAME to libgeotiff.so.1.2.2, i.e. binaries are being > dynamically linked against libgeotiff.so.1.2.2: > > ldd /usr/bin/geotifcp > ... > libgeotiff.so.1.2.2 => /usr/lib/libgeotiff.so.1.2.2 (0x007ce000) > > The SONAME should better be libgeotiff.so.1 > >> > You also want to include the following directories in the binary >> packages: >> > >> > /usr/include/geotiff/ >> > /usr/share/epsg_csv/ > Exactly. This is not yet fixed yet. > >> > Some of Ralf's findings are not fixed yet. > The bogus Provides: line is still present. > > I am proposing the patch to libgeotiff.spec and to the Makefile, below. > > An issue I haven't looked into: libgeotiff.so.1.2.2 contains references > to other libraries (e.g. libtiff). So it could be reasonable to let the > *-devel package require further *-devel packages (e.g. libtiff-devel). > > Ralf > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From rms at 1407.org Mon Jul 18 06:56:53 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 18 Jul 2005 07:56:53 +0100 Subject: Ownership claim: MagicPoint In-Reply-To: <42DAFE7D.5080608@redhat.com> References: <1121597106.18089.18.camel@roque> <604aa7910507171202e53891d@mail.gmail.com> <1121627677.2923.17.camel@roque> <42DAFE7D.5080608@redhat.com> Message-ID: <1121669813.2923.42.camel@roque> On Sun, 2005-07-17 at 14:57 -1000, Warren Togami wrote: > Pointing to a Red Hat is not an excuse not to read and follow the rules. As could have been seen from the nautilus-open-terminal package I did, I not only read and followed the rules, I followed them to a pedant extreme. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 erdinc at prosoft.com.tr Mon Jul 18 11:05:01 2005 From: erdinc at prosoft.com.tr (Ali =?ISO-8859-9?Q?Erdin=E7_K=F6ro=F0lu?=) Date: Mon, 18 Jul 2005 14:05:01 +0300 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian Message-ID: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I would like to prepare Clamav, Amavisd-new, Pyzor, DCC and Dansguardian packages so is there any maintainer for them? if not I want to take the responsibility. Regards Ali Erdinc Koroglu http://www.prosoft.com.tr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC24zdUZ8xvL9ToPoRAmEJAKC567mnVj13lWxUQHbR/RxFaiJo0ACfbBAf xoJdMODaEBjtvPKN/wYe3zg= =xAbT -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Mon Jul 18 08:13:00 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 10:13:00 +0200 (CEST) Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> Message-ID: <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> On Lun 18 juillet 2005 13:05, Ali Erdin? K?ro?lu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > I would like to prepare Clamav, Amavisd-new, Pyzor, DCC and Dansguardian > packages > so is there any maintainer for them? if not I want to take the > responsibility. clamav and pyzor (and razor, spamassassin) are already packaged. amavisd-new isn't but all deps should already be taken care of. The difficult part is to automate cleanly clamav and MTA integration. Last time I checked DCC was not OSS and/or a bastard to package. Never looked at Dansguardian -- Nicolas Mailhot From wtogami at redhat.com Mon Jul 18 08:25:52 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Jul 2005 22:25:52 -1000 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> Message-ID: <42DB6790.4040403@redhat.com> Nicolas Mailhot wrote: > > clamav and pyzor (and razor, spamassassin) are already packaged. > > amavisd-new isn't but all deps should already be taken care of. The > difficult part is to automate cleanly clamav and MTA integration. > > Last time I checked DCC was not OSS and/or a bastard to package. > > Never looked at Dansguardian > http://togami.com/~warren/fedora/DansGuardian-2.7.1-0.fdr.1.src.rpm I looked at DansGuardian a very long time ago and began cleaning up this package, but then I gave up on it after I realized that it is absolutely horrible software from both a technical and societal point of view. I think squidguard is much better designed software, but the source of your blacklist is a separate problem. DCC is indeed not OSS and very much bastard to package... unless we agree to allow fakeroot in Fedora. Apparently Debian sometimes uses fakeroot. I'm not sure fakeroot would be something we want to encourage here though. It seems to encourage laziness. Warren Togami wtogami at redhat.com From oliver at linux-kernel.at Mon Jul 18 08:26:06 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 18 Jul 2005 10:26:06 +0200 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> Message-ID: <42DB679E.9050309@linux-kernel.at> On 07/18/2005 10:13 AM, Nicolas Mailhot wrote: > On Lun 18 juillet 2005 13:05, Ali Erdin? K?ro?lu wrote: >>Hi all, >>I would like to prepare Clamav, Amavisd-new, Pyzor, DCC and Dansguardian >>packages >>so is there any maintainer for them? if not I want to take the >>responsibility. > > > clamav and pyzor (and razor, spamassassin) are already packaged. > > amavisd-new isn't but all deps should already be taken care of. The > difficult part is to automate cleanly clamav and MTA integration. > > Last time I checked DCC was not OSS and/or a bastard to package. You may have a look at my dcc package: http://filelister.linux-kernel.at/downloads/packages/lkernAT/SRPMS/dcc-1.3.0-1.src.rpm I took that from Mandrake some time ago and updated it. But the last update is allready a while ago. Actuall version is 1.3.6 and mine is 1.3.0. And license: The Distributed Checksum Clearinghouse source carries a license that is free to organizations that do not sell filtering devices or services except to their own users and that participate in the global DCC network. (I.e. ISPs that use the DCC to filter mail for their own users are intended to be covered in the free license.) You also can't call it your own or blame anyone for using it. It shouldn't be a problem to included it!? In my spec: BSD-like (but I told you, copied that from Mandrake). Best, Oliver From oliver at linux-kernel.at Mon Jul 18 08:29:08 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 18 Jul 2005 10:29:08 +0200 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <42DB6790.4040403@redhat.com> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> <42DB6790.4040403@redhat.com> Message-ID: <42DB6854.3090306@linux-kernel.at> On 07/18/2005 10:25 AM, Warren Togami wrote: > Nicolas Mailhot wrote: >> >> clamav and pyzor (and razor, spamassassin) are already packaged. >> >> amavisd-new isn't but all deps should already be taken care of. The >> difficult part is to automate cleanly clamav and MTA integration. >> >> Last time I checked DCC was not OSS and/or a bastard to package. >> >> Never looked at Dansguardian >> > > http://togami.com/~warren/fedora/DansGuardian-2.7.1-0.fdr.1.src.rpm > I looked at DansGuardian a very long time ago and began cleaning up this > package, but then I gave up on it after I realized that it is absolutely > horrible software from both a technical and societal point of view. I > think squidguard is much better designed software, but the source of > your blacklist is a separate problem. And squidguard is on my tasklist to be include in FE: http://filelister.linux-kernel.at/downloads/packages/lkernAT/SRPMS/squidGuard-1.2.0-7.src.rpm :-) > DCC is indeed not OSS and very much bastard to package... unless we > agree to allow fakeroot in Fedora. Apparently Debian sometimes uses > fakeroot. I'm not sure fakeroot would be something we want to encourage > here though. It seems to encourage laziness. See my other mail... Best, Oliver From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jul 18 08:57:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 18 Jul 2005 10:57:50 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <1121523413.17248.4.camel@shuttle.273piedmont.com> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> Message-ID: <20050718105750.58ab75e4@python2> Brian Pepple wrote : > On Thu, 2005-07-14 at 21:21 +0200, Matthias Saou wrote: > > Well, in that case, I'd be interested in hearing your comments regarding > > the possibility of having a "gkrellm-xmms" package that would obsolete > > "gkrellmms". You can find such a package next to the "gkrellm-bmp" one. A > > quick review of both would be much appreciated too ;-) > > The specs look ok, but is there any reason for not following the > upstream name? According to the wiki, we should try to follow the > upstream name, and I don't see any compelling reason not to follow that. In this particular case, there are two reasons : - The name space for an application's plugins should be "appname-pluginname", and this is what some gkrellm plugins already use upstream, but unfortunately not all. See the "Addon Packages (General)" section of the Package Naming Guidelines. - Both gkrellm-xmms and gkrellm-bmp are built from the same "gkrellmms" source, but are mutually exclusive, so it would be impossible to have both keep the name, and deciding to name the bmp version "gkrellbmp" for instance seems much uglier to me than choosing to use the "gkrellm-*" name space. Oh and another one is that "yum search gkrellm-*" will return _all_ gkrellm related packages if they are all included in that name space. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.34 0.60 0.83 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jul 18 09:06:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 18 Jul 2005 11:06:11 +0200 Subject: djvulibre for fc4 x86_64 In-Reply-To: <42D9F5BA.2030200@gmail.com> References: <42D9F5BA.2030200@gmail.com> Message-ID: <20050718110611.1409dc01@python2> Kevac Marko wrote : > Have somebody already build djvulibre for fc4 x86_64? The build failed. I've already tried looking into it, but never finished fixing it. Here's the current bugzilla entry for it : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156208 I saw last week that nrpms.net had built for FC4 a CVS snapshot instead of the last released version. This may be another solution if the bugs have been fixed upstream but no new version released yet. Feel free to comment and contribute in the above bug entry. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1390_FC4.s3 Load : 0.42 0.61 0.76 From menno-fedora at freshfoo.com Mon Jul 18 11:37:33 2005 From: menno-fedora at freshfoo.com (Menno Smits) Date: Mon, 18 Jul 2005 21:37:33 +1000 Subject: Request for review: devilspie Message-ID: <42DB947D.1030308@freshfoo.com> Hi, I've just packaged Devil's Pie, a window matching utility for X. Spec, srpm and rpm at: http://freshfoo.com/fedora/devilspie/ From the %description: A window-matching utility, inspired by Sawfish's "Matched Windows" option and the lack such functionality in Metacity. Devil's Pie can be configured to detect windows as they are created, and match the window to a set of rules. If the window matches the rules, it can perform a series of actions on that window. For example, I can make X-Chat appear on all workspaces, and make a particular xterm not appear in the pager or task list. Thanks, Menno From pmatilai at laiskiainen.org Mon Jul 18 11:51:03 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 18 Jul 2005 14:51:03 +0300 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121466335.3250.5.camel@localhost.localdomain> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> Message-ID: <1121687463.7259.2.camel@weasel.turre.laiskiainen.org> On Fri, 2005-07-15 at 18:25 -0400, Paul W. Frields wrote: > > Sorry to reply to myself. New off-Broadway version 0.4-4 fixes other > discrepancies from spot's reviewer guidelines: > > http://rpm.frields.org/FC5/nautilus-open-terminal/ Doesn't build on x86_64: gcc -shared .libs/nautilus-open-terminal.o .libs/open-terminal.o -lnautilus-extension -pthread -L/usr/X11R6/lib64 -lgnome-desktop-2 -lgnomeui-2 -lSM -lICE -lstartup-notification-1 -lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 /usr/lib/libpopt.so -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -m64 -mtune=nocona -Wl,--export-dynamic -Wl,--export-dynamic -Wl,--export-dynamic -Wl,-soname -Wl,libnautilus-open-terminal.so -o .libs/libnautilus-open-terminal.so /usr/lib/libpopt.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [libnautilus-open-terminal.la] Error 1 make[2]: Leaving directory `/home/pmatilai/rpm/BUILD/nautilus-open-terminal-0.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/pmatilai/rpm/BUILD/nautilus-open-terminal-0.4'make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.55284 (%build) Running aclocal + autoconf before %configure seems to fix that. - Panu - From stickster at gmail.com Mon Jul 18 12:11:02 2005 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 18 Jul 2005 08:11:02 -0400 Subject: Review nautilus-open-terminal was Re: No more right click terminal In-Reply-To: <1121687463.7259.2.camel@weasel.turre.laiskiainen.org> References: <1121143049.3521.16.camel@localhost.localdomain> <1121245649.12224.28.camel@localhost.localdomain> <1121248417.16074.19.camel@goose> <1121274056.10565.15.camel@nexus.verbum.private> <1121294559.31376.56.camel@prometheus.gamehouse.com> <1121300226.3826.31.camel@localhost.localdomain> <1121355796.3094.18.camel@enki.eridu> <1121369647.5118.4.camel@localhost.localdomain> <1121372812.3523.15.camel@enki.eridu> <1121376609.2975.3.camel@localhost.localdomain> <1121466335.3250.5.camel@localhost.localdomain> <1121687463.7259.2.camel@weasel.turre.laiskiainen.org> Message-ID: <1121688662.3084.6.camel@localhost.localdomain> On Mon, 2005-07-18 at 14:51 +0300, Panu Matilainen wrote: > On Fri, 2005-07-15 at 18:25 -0400, Paul W. Frields wrote: > > > > > Sorry to reply to myself. New off-Broadway version 0.4-4 fixes other > > discrepancies from spot's reviewer guidelines: > > > > http://rpm.frields.org/FC5/nautilus-open-terminal/ > > Doesn't build on x86_64: > gcc -shared .libs/nautilus-open-terminal.o .libs/open-terminal.o > -lnautilus-extension -pthread -L/usr/X11R6/lib64 -lgnome-desktop-2 > -lgnomeui-2 -lSM -lICE -lstartup-notification-1 -lbonoboui-2 -lxml2 > -lpthread -lz -lgnomecanvas-2 -lgnome-2 /usr/lib/libpopt.so -lart_lgpl_2 > -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 > -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 > -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 > -ldl -lgthread-2.0 -lglib-2.0 -m64 -mtune=nocona -Wl,--export-dynamic > -Wl,--export-dynamic -Wl,--export-dynamic -Wl,-soname > -Wl,libnautilus-open-terminal.so -o .libs/libnautilus-open-terminal.so > /usr/lib/libpopt.so: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > make[2]: *** [libnautilus-open-terminal.la] Error 1 > make[2]: Leaving directory > `/home/pmatilai/rpm/BUILD/nautilus-open-terminal-0.4/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/pmatilai/rpm/BUILD/nautilus-open-terminal-0.4'make: *** [all] > Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.55284 (%build) > > Running aclocal + autoconf before %configure seems to fix that. Thanks, reported in Bugzilla as #163463 already, and fixed in CVS (0.4-5) last night. I need to update the build request. See: http://www.redhat.com/archives/fedora-extras-commits/2005-July/msg01148.html http://www.redhat.com/archives/fedora-extras-commits/2005-July/msg01157.html Please feel free to check the build from CVS. I'm a bit new at this and unsure how long build requests take to process. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Jul 18 13:42:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Jul 2005 08:42:08 -0500 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <42DB679E.9050309@linux-kernel.at> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> <42DB679E.9050309@linux-kernel.at> Message-ID: <1121694128.32518.3.camel@localhost.localdomain> On Mon, 2005-07-18 at 10:26 +0200, Oliver Falk wrote: > The Distributed Checksum Clearinghouse source carries a license that is > free to organizations that do not sell filtering devices or services > except to their own users and that participate in the global DCC > network. (I.e. ISPs that use the DCC to filter mail for their own users > are intended to be covered in the free license.) You also can't call it > your own or blame anyone for using it. Thats a screwed up license. It's no better than the "for non-commercial use only" licenses. We can't control who uses FE packages, so any license with usage restrictions is almost definitely not ok. I'm voting no on this one. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From steve at silug.org Mon Jul 18 14:12:23 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 09:12:23 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite Message-ID: <20050718141223.GA14908@osiris.silug.org> amavisd-new (which I'm working on right now) and spamassassin both want this: http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-1.src.rpm And this is a dependency: http://ftp.kspei.com/pub/steve/rpms/perl-Net-CIDR-Lite-0.18-1.src.rpm 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Mon Jul 18 14:17:15 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 09:17:15 -0500 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> Message-ID: <20050718141715.GA14709@osiris.silug.org> On Mon, Jul 18, 2005 at 02:05:01PM +0300, Ali Erdin? K?ro?lu wrote: > I would like to prepare Clamav, Amavisd-new, Pyzor, DCC and > Dansguardian packages so is there any maintainer for them? if not I > want to take the responsibility. I'm working on amavisd-new. I should be submitting it for approval this week. (I'm testing the package right now on a new mail server.) 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 oliver at linux-kernel.at Mon Jul 18 14:32:32 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 18 Jul 2005 16:32:32 +0200 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <1121694128.32518.3.camel@localhost.localdomain> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> <42DB679E.9050309@linux-kernel.at> <1121694128.32518.3.camel@localhost.localdomain> Message-ID: <42DBBD80.3080506@linux-kernel.at> On 07/18/2005 03:42 PM, Tom 'spot' Callaway wrote: > On Mon, 2005-07-18 at 10:26 +0200, Oliver Falk wrote: > > >>The Distributed Checksum Clearinghouse source carries a license that is >>free to organizations that do not sell filtering devices or services >>except to their own users and that participate in the global DCC >>network. (I.e. ISPs that use the DCC to filter mail for their own users >>are intended to be covered in the free license.) You also can't call it >>your own or blame anyone for using it. > > > Thats a screwed up license. It's no better than the "for non-commercial > use only" licenses. > > We can't control who uses FE packages, so any license with usage > restrictions is almost definitely not ok. I'm voting no on this one. This is OK from my side. Best, Oliver From jspaleta at gmail.com Mon Jul 18 14:43:11 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 18 Jul 2005 10:43:11 -0400 Subject: Ownership claim: MagicPoint In-Reply-To: <1121627677.2923.17.camel@roque> References: <1121597106.18089.18.camel@roque> <604aa7910507171202e53891d@mail.gmail.com> <1121627677.2923.17.camel@roque> Message-ID: <604aa79105071807437da001fa@mail.gmail.com> On 7/17/05, Rui Miguel Seabra wrote: > What would you advise? I followed this procedure since it's not a new > package, but I can just as easily change. In general I would say its a good idea to ask for review of any package, even an orphaned one, before you import it to get help making sure the spec is conformat to the evolving standards for extras. Sure, according to the process, established contributors with cvs access don't need to get explicit approval to get an orphaned package back into the build system, but its always a good idea to do a round of review and clean up the spec. This is especially true for new contributors who aren't maintaining a package yet inside core or extras. The front loaded review process is a useful mechanism for mentoring and discussion. -jef From paul at city-fan.org Mon Jul 18 14:51:48 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 18 Jul 2005 15:51:48 +0100 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718141223.GA14908@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> Message-ID: <42DBC204.6030406@city-fan.org> Steven Pritchard wrote: > amavisd-new (which I'm working on right now) and spamassassin both > want this: > > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-1.src.rpm > > And this is a dependency: > > http://ftp.kspei.com/pub/steve/rpms/perl-Net-CIDR-Lite-0.18-1.src.rpm Starting with perl-Net-CIDR-Lite-0.18-1.src.rpm: Good: - rpmlint cleam - package name obviously correct - spec file name correct - license correct - tarball md5sum matches upstream - package builds fine on FC4 - no buildrequires needed - no locale data to worry about - no shared libraries to worry about - no relocations - all directories owned properly - no duplicate files - no bogus permissions - clean section present and correct - no optimization macros needed for noarch perl package - package contains code, not content - no large documentation files - docs don't affect running of code - no header files, libraries or pkgconfig files to worry about - no scriptlets or subpackages to worry about Bad: - license text not included in %%doc I guess you could auto-generate this using: perldoc -t perlgpl and perldoc -t perlartistic Virtually all other perl module packages in Extras also neglect to include the license text, so I don't know how hard and fast this particular rule is. If you want to include the license text, I'm happy to approve this package; otherwise we'll have to have another debate - last time we had it the consensus appeared to be that the license text should be included, despite the multiple bad precedents. Paul. From steve at silug.org Mon Jul 18 15:18:12 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 10:18:12 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <42DBC204.6030406@city-fan.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBC204.6030406@city-fan.org> Message-ID: <20050718151812.GA15984@osiris.silug.org> On Mon, Jul 18, 2005 at 03:51:48PM +0100, Paul Howarth wrote: > Bad: > - license text not included in %%doc > > I guess you could auto-generate this using: > > perldoc -t perlgpl > and > perldoc -t perlartistic > > Virtually all other perl module packages in Extras also neglect to > include the license text, so I don't know how hard and fast this > particular rule is. Since most perl modules just say "you can redistribute it and/or modify it under the same terms as Perl itself" (the README included in %doc says that), I would think that would be good enough. If the module includes Artistic or COPYING, I would definitely include it in the package, but generating it for each package that doesn't seems a bit excessive to me. I'm not violently opposed to the idea or anything though, so if that's what is decided, I'll do it... 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 paul at city-fan.org Mon Jul 18 15:26:04 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 18 Jul 2005 16:26:04 +0100 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718141223.GA14908@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> Message-ID: <42DBCA0C.1060506@city-fan.org> Steven Pritchard wrote: > amavisd-new (which I'm working on right now) and spamassassin both > want this: > > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-1.src.rpm Good: - package name obviously correct - spec file name correct - license correct - tarball md5sum matches upstream - package builds fine on FC4 - no buildrequires needed - no locale data to worry about - no shared libraries to worry about - no relocations - all directories owned properly - no duplicate files - no bogus permissions - clean section present and correct - no optimization macros needed for noarch perl package - package contains code, not content - no large documentation files - docs don't affect running of code - no header files, libraries or pkgconfig files to worry about - no scriptlets or subpackages to worry about Bad: - missing BuildRequires (from Makefile.PL): perl(Net::DNS) >= 0.46, perl(Net::CIDR::Lite) >= 0.15, perl(Sys::Hostname::Long) >= 1.0 the latter is not yet included in Extras or up for review - rpmlint output not empty, due to permissions issues on and in the samples directory. I'd fix the 2755 permission on the samples directory itself but wouldn't worry about the non-executable scripts in there (which are %%doc files) - license text not included in %%doc For discussion: - the test phase is skipped because it does a lot of external DNS lookups - is this the right thing to do? - there is a bug in the handling of non-SPF TXT records with "fallback" in Mail::SPF::Query; the attached patch is what I use in my own package of this module to fix it. I'd like to see spfd and spfquery brought into the alternatives system. This is because there are other implementations of these (e.g. in libspf and libspf2, both of which I hope to include in extras when they're ready), and it would be useful to be able to install them in parallel with this package. Here's what I do: Requires(post): %{_sbindir}/alternatives Requires(preun): %{_sbindir}/alternatives Requires(postun): %{_sbindir}/alternatives In %install: mv $RPM_BUILD_ROOT%{_bindir}/spfquery $RPM_BUILD_ROOT%{_bindir}/spfquery.Mail::SPF::Query mv $RPM_BUILD_ROOT%{_bindir}/spfd $RPM_BUILD_ROOT%{_bindir}/spfd.Mail::SPF::Query Add scriptlets: %post %{_sbindir}/alternatives --install %{_bindir}/spfquery spf %{_bindir}/spfquery.Mail::SPF::Query 50 \ --slave %{_bindir}/spfd spf-daemon %{_bindir}/spfd.Mail::SPF::Query exit 0 %preun if [ $1 = 0 ]; then %{_sbindir}/alternatives --remove spf %{_bindir}/spfquery.Mail::SPF::Query fi exit 0 %postun if [ "$1" -ge "1" ]; then spf=`%{_bindir}/readlink /etc/alternatives/spf` if [ "$spf" == "%{_bindir}/spfquery.Mail::SPF::Query" ]; then %{_sbindir}/alternatives --set spf %{_bindir}/spfquery.Mail::SPF::Query fi fi exit 0 Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: MSQ-fallback.patch Type: text/x-patch Size: 728 bytes Desc: not available URL: From paul at city-fan.org Mon Jul 18 15:31:01 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 18 Jul 2005 16:31:01 +0100 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718151812.GA15984@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBC204.6030406@city-fan.org> <20050718151812.GA15984@osiris.silug.org> Message-ID: <42DBCB35.2060802@city-fan.org> Steven Pritchard wrote: > On Mon, Jul 18, 2005 at 03:51:48PM +0100, Paul Howarth wrote: > >>Bad: >>- license text not included in %%doc >> >>I guess you could auto-generate this using: >> >>perldoc -t perlgpl >>and >>perldoc -t perlartistic >> >>Virtually all other perl module packages in Extras also neglect to >>include the license text, so I don't know how hard and fast this >>particular rule is. > > > Since most perl modules just say "you can redistribute it and/or > modify it under the same terms as Perl itself" (the README included in > %doc says that), I would think that would be good enough. If the > module includes Artistic or COPYING, I would definitely include it in > the package, but generating it for each package that doesn't seems a > bit excessive to me. > > I'm not violently opposed to the idea or anything though, so if that's > what is decided, I'll do it... I agree with you personally, but not everyone else does. See: https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00039.html for the last time I brought this up. Paul. From ondrejj at salstar.sk Mon Jul 18 15:31:06 2005 From: ondrejj at salstar.sk (Jan ONDREJ (SAL)) Date: Mon, 18 Jul 2005 17:31:06 +0200 Subject: Request for review: SAGATOR Message-ID: <20050718153105.GB25492@salstar.sk> Hello, Spec/srpms/i386.rpms: http://www.salstar.sk/pub/sagator/fedora/extras/ Description: This program is an email antivirus/antispam gateway. It is an interface to the postfix, sendmail, or any other smtpd, which runs antivirus and/or spamchecker. Its modular architecture can use any combination of antivirus/spamchecker according to configuration. It has some internal checkers (string_scanner and regexp_scanner). Sagator can parse MIME mails and decompress archives, if it is configured so. Features: * simple chroot support * modular antivirus/spamchecker support * you don't need any perl modules or any other modules, only python * you can return any quarantined mail to mailq/user mailbox * mailbox/maildir scanning and mailbox cleaning * nice statistics via WWW or MRTG * easy installation In latest development release there are supports for http proxy filtering, daily summarty reports, web quarantine (access to it's quarantine over WWW interface). rpmlint report's only one error: configure-without-libdir-spec, but it is an error of rpmlint (because it has no support for libdir parameter without =). I also have no sponsor or CVS access. Jan ONDREJ (SAL) From nicolas.mailhot at laposte.net Mon Jul 18 15:41:30 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 17:41:30 +0200 (CEST) Subject: Request for review: SAGATOR In-Reply-To: <20050718153105.GB25492@salstar.sk> References: <20050718153105.GB25492@salstar.sk> Message-ID: <43166.192.54.193.37.1121701290.squirrel@rousalka.dyndns.org> On Lun 18 juillet 2005 17:31, Jan ONDREJ (SAL) wrote: > Hello, Hi > Spec/srpms/i386.rpms: > http://www.salstar.sk/pub/sagator/fedora/extras/ > > Description: > > This program is an email antivirus/antispam gateway. It is an interface to > the postfix, sendmail, or any other smtpd, which runs antivirus and/or > spamchecker. Its modular architecture can use any combination of > antivirus/spamchecker according to configuration. How does it compare to amavisd-new for example ? Regards, -- Nicolas Mailhot From ondrejj at salstar.sk Mon Jul 18 16:25:54 2005 From: ondrejj at salstar.sk (ondrejj at salstar.sk) Date: Mon, 18 Jul 2005 18:25:54 +0200 Subject: Request for review: SAGATOR In-Reply-To: <43166.192.54.193.37.1121701290.squirrel@rousalka.dyndns.org> References: <20050718153105.GB25492@salstar.sk> <43166.192.54.193.37.1121701290.squirrel@rousalka.dyndns.org> Message-ID: <20050718182554.18khen6tvs40sc00@www.salstar.sk> Hi, Quoting Nicolas Mailhot : >> Spec/srpms/i386.rpms: >> http://www.salstar.sk/pub/sagator/fedora/extras/ >> >> Description: >> >> This program is an email antivirus/antispam gateway. It is an interface to >> the postfix, sendmail, or any other smtpd, which runs antivirus and/or >> spamchecker. Its modular architecture can use any combination of >> antivirus/spamchecker according to configuration. > > How does it compare to amavisd-new for example ? It is an alternate product. You can see mentioned features for compare. I have no experience with amavisd-new, because sagator has similiar age. SAL ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From steve at silug.org Mon Jul 18 17:53:03 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 12:53:03 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <42DBCA0C.1060506@city-fan.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> Message-ID: <20050718175303.GA18769@osiris.silug.org> On Mon, Jul 18, 2005 at 04:26:04PM +0100, Paul Howarth wrote: > Bad: > - missing BuildRequires (from Makefile.PL): > perl(Net::DNS) >= 0.46, Since I'm not doing "make test", this isn't a build requirement. That said, the version isn't getting picked up automatically, so I'll fix that. > perl(Net::CIDR::Lite) >= 0.15, Ditto. > perl(Sys::Hostname::Long) >= 1.0 Again, it's not really a build requirement, because we're not doing "make test". Besides, that's an optional module. 250 eval { require Sys::Hostname::Long }; 251 $query->{myhostname} = $@ ? hostname() : Sys::Hostname::Long::hostname_long(); > the latter is not yet included in Extras or up for review All that said, I don't mind whipping up a package for it... > - rpmlint output not empty, due to permissions issues on and in the > samples directory. I'd fix the 2755 permission on the samples directory > itself but wouldn't worry about the non-executable scripts in there > (which are %%doc files) 2755? The directory looks right to me. drwxr-xr-x 2 root root 0 Apr 26 2004 /usr/share/doc/perl-Mail-SPF-Query-1.997/sample And you're right, the scripts themselves are just %doc, so there's really no reason for them to be executable. > - license text not included in %%doc We'll have to discuss that... > For discussion: > - the test phase is skipped because it does a lot of external DNS > lookups - is this the right thing to do? It was failing intermittently here. I hate to have that kind of uncertaintly in a package build. > - there is a bug in the handling of non-SPF TXT records with "fallback" > in Mail::SPF::Query; the attached patch is what I use in my own package > of this module to fix it. I'll take a look at that. > I'd like to see spfd and spfquery brought into the alternatives system. > This is because there are other implementations of these (e.g. in libspf > and libspf2, both of which I hope to include in extras when they're > ready), and it would be useful to be able to install them in parallel > with this package. Maybe they should just be included as %doc? I don't have any strong feelings about them being in $PATH. 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 steve at silug.org Mon Jul 18 18:16:46 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 13:16:46 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718175303.GA18769@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> Message-ID: <20050718181646.GB18769@osiris.silug.org> On Mon, Jul 18, 2005 at 12:53:03PM -0500, Steven Pritchard wrote: > > perl(Sys::Hostname::Long) >= 1.0 [...] > Besides, that's an optional module. > > 250 eval { require Sys::Hostname::Long }; > 251 $query->{myhostname} = $@ ? hostname() : Sys::Hostname::Long::hostname_long(); Looking at Sys::Hostname::Long a bit, I'm pretty sure using it on Linux would be a complete waste. It appears to be mostly for working around bugs on other operating systems. I don't see any reason to include it in Extras (at least not for this). 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 steve at silug.org Mon Jul 18 18:27:30 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 13:27:30 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <42DBCA0C.1060506@city-fan.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> Message-ID: <20050718182730.GC18769@osiris.silug.org> Other than the whole issue of importing a copy of the license from the main perl package, this should fix the outstanding issues: http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-2.src.rpm 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 ville.skytta at iki.fi Mon Jul 18 20:07:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 18 Jul 2005 23:07:30 +0300 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718175303.GA18769@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> Message-ID: <1121717250.14525.48.camel@localhost.localdomain> On Mon, 2005-07-18 at 12:53 -0500, Steven Pritchard wrote: > On Mon, Jul 18, 2005 at 04:26:04PM +0100, Paul Howarth wrote: > > > For discussion: > > - the test phase is skipped because it does a lot of external DNS > > lookups - is this the right thing to do? > > It was failing intermittently here. I hate to have that kind of > uncertaintly in a package build. Working external DNS or network access is not something we should IMO assume being available in build roots. And besides, as noted; even if it's available, it may cause build failures due to DNS issues, which makes the test suite less useful. Without having a look at the specfile or the package: unless it's already there it would be useful to have the %check section and "make test" in it though, the latter commented out and the reasoning documented next to it. Or if possible, leave it uncommented and disable only the tests that require network access. From Nicolas.Mailhot at laPoste.net Mon Jul 18 20:27:48 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 22:27:48 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718181646.GB18769@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <20050718181646.GB18769@osiris.silug.org> Message-ID: <1121718468.7652.1.camel@rousalka.dyndns.org> Le lundi 18 juillet 2005 ? 13:16 -0500, Steven Pritchard a ?crit : > On Mon, Jul 18, 2005 at 12:53:03PM -0500, Steven Pritchard wrote: > > > perl(Sys::Hostname::Long) >= 1.0 > [...] > > Besides, that's an optional module. > > > > 250 eval { require Sys::Hostname::Long }; > > 251 $query->{myhostname} = $@ ? hostname() : Sys::Hostname::Long::hostname_long(); > > Looking at Sys::Hostname::Long a bit, I'm pretty sure using it on > Linux would be a complete waste. It appears to be mostly for working > around bugs on other operating systems. I don't see any reason to > include it in Extras (at least not for this). However something must be done about it else maillog fils with : Jul 18 22:25:17 rousalka spamassassin[20168]: Can't locate Sys/Hostname/Long.pm in @INC (@INC contains: ../lib /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-thread-multi /usr/lib/perl5/5.8.6) at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SPF/Query.pm line 328, line 74. (good job about amavis btw) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laPoste.net Mon Jul 18 20:35:02 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 22:35:02 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718182730.GC18769@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> Message-ID: <1121718903.7652.3.camel@rousalka.dyndns.org> You also need to submit perl-BerkeleyDB for amavis BTW (just in case you forgot) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Jul 18 20:38:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 18 Jul 2005 23:38:27 +0300 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121718903.7652.3.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> Message-ID: <1121719107.14525.67.camel@localhost.localdomain> On Mon, 2005-07-18 at 22:35 +0200, Nicolas Mailhot wrote: > You also need to submit perl-BerkeleyDB for amavis BTW (just in case you > forgot) ...and feel free to borrow mine if you do. http://cachalot.mine.nu/4/SRPMS/perl-BerkeleyDB-0.26-0.1.src.rpm From Nicolas.Mailhot at laPoste.net Mon Jul 18 20:42:57 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 22:42:57 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121718903.7652.3.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> Message-ID: <1121719378.7652.7.camel@rousalka.dyndns.org> Le lundi 18 juillet 2005 ? 22:35 +0200, Nicolas Mailhot a ?crit : > You also need to submit perl-BerkeleyDB for amavis BTW (just in case you > forgot) It's missing perl-Test-Pod and perl-MLDBM as BuildRequires (they're in FE why not use them) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laPoste.net Mon Jul 18 21:42:10 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 18 Jul 2005 23:42:10 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121719378.7652.7.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> <1121719378.7652.7.camel@rousalka.dyndns.org> Message-ID: <1121722930.7652.18.camel@rousalka.dyndns.org> Le lundi 18 juillet 2005 ? 22:42 +0200, Nicolas Mailhot a ?crit : > Le lundi 18 juillet 2005 ? 22:35 +0200, Nicolas Mailhot a ?crit : > > You also need to submit perl-BerkeleyDB for amavis BTW (just in case you > > forgot) > > It's missing perl-Test-Pod and perl-MLDBM as BuildRequires (they're in > FE why not use them) And also, for amavis itself : - pid file location in conf file needs work - same for the clamav socket location - do we want to send virus notifications by default ? - you need to add /var/spool/amavisd/db/ to the directory list - I don't like the default logging level of 0 :) - does the clamav conf file needs to be readable by all ? - do you need to create an amavisd sundir in /etc to host a single file ? - didn't check if you enabled quarantining, if you did you have to provide a script that scrubs the quarantine every so often (I had chosen to disable quarantine in my old spec) - needs some postfix integration (at least add a commented instruction block to the postifx conf files). The /usr/share/doc/amavisd-new-2.3.2/README_FILES/README.postfix is a bit too much for your average user. That's all for a quick overview, it seems to run now, let's see how it goes. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laPoste.net Mon Jul 18 22:04:09 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 19 Jul 2005 00:04:09 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121722930.7652.18.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> <1121719378.7652.7.camel@rousalka.dyndns.org> <1121722930.7652.18.camel@rousalka.dyndns.org> Message-ID: <1121724249.7652.20.camel@rousalka.dyndns.org> Le lundi 18 juillet 2005 ? 23:42 +0200, Nicolas Mailhot a ?crit : > And also, for amavis itself : > > - pid file location in conf file needs work ... - is /var/log/amavisd/ used for anything ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon Jul 18 22:24:30 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Jul 2005 17:24:30 -0500 Subject: potential candidates for contribution In-Reply-To: <1111055449.5979.9.camel@localhost.localdomain> References: <1111010485.7403.25.camel@localhost.localdomain> <1111043061.18744.23.camel@ignacio.ignacio.lan> <1111048434.5979.2.camel@localhost.localdomain> <1111052040.12978.19.camel@speedy.iagorubio.net> <1111055449.5979.9.camel@localhost.localdomain> Message-ID: <1121725470.32518.39.camel@localhost.localdomain> On Thu, 2005-03-17 at 11:30 +0100, Rudolf Kastl wrote: > 1. trigger - 3d rallye game. > 3. flightgear - 3d flight simulator > > RPMS: http://newrpms.sunsite.dk/apt/redhat/en/i386/fc3/RPMS.newrpms/ > SRPMS: http://newrpms.sunsite.dk/apt/redhat/en/i386/fc3/SRPMS.newrpms/ Rudolf, Are you still interested in maintaining trigger, flightgear, and physfs in Fedora Extras? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From andreas at bawue.net Mon Jul 18 22:35:00 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 19 Jul 2005 00:35:00 +0200 (CEST) Subject: potential candidates for contribution In-Reply-To: <1121725470.32518.39.camel@localhost.localdomain> References: <1111010485.7403.25.camel@localhost.localdomain> <1111043061.18744.23.camel@ignacio.ignacio.lan> <1111048434.5979.2.camel@localhost.localdomain> <1111052040.12978.19.camel@speedy.iagorubio.net> <1111055449.5979.9.camel@localhost.localdomain> <1121725470.32518.39.camel@localhost.localdomain> Message-ID: On Mon, 18 Jul 2005, Tom 'spot' Callaway wrote: > Are you still interested in maintaining trigger, flightgear, and physfs > in Fedora Extras? Hmmm. I have a packaged flightgear and simgear package ready. We could include this... Only difference, it's named SimGear and FlightGear, as upstream capitalised the name. bye, andreas From roland at redhat.com Mon Jul 18 22:44:09 2005 From: roland at redhat.com (Roland McGrath) Date: Mon, 18 Jul 2005 15:44:09 -0700 (PDT) Subject: Please review: monotone Message-ID: <20050718224409.10AE02207D3@magilla.sf.frob.com> Ok, let's get this show on the road. There are several of us who have proposed monotone rpms. I haven't heard anything like a clear approval, and I can't figure out who it is who ought to be stepping forward to do that. I would be happy to be the maintainer, as probably would each other who has proposed it. I'm ready to go right now if I can figure out what constitutes proper approval. monotone 0.21 was just released, and it builds out of the box on FC4 and on rawhide. Below is my current version of the spec file. I've added the emacs support to the rpm. I'll probably keep tweaking it, and may add some other stuff to make it simpler to run a monotone netsync server. This works just fine as it is. Someone please tell me to commit it already. Thanks, Roland Name: monotone Version: 0.21 Release: 1%{?dist} Summary: A free, distributed version control system Group: Development/Tools License: GPL URL: http://www.venge.net/monotone/ Source0: http://www.venge.net/monotone/downloads/%{name}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: boost-devel >= 1.32.0 BuildRequires: lua %if 1 %define bundled_sqlite yes %else # in fact, monotone has a locally-hacked 3.2.2, so we can't replace it BuildRequires: sqlite-devel >= 3.2.2 %define bundled_sqlite no %endif BuildRequires: emacs Requires(post): /sbin/install-info Requires(postun): /sbin/install-info %description monotone is a free, distributed version control system. It provides fully disconnected operation, manages complete tree versions, keeps its state in a local transactional database, supports overlapping branches and extensible metadata, exchanges work over plain network protocols, performs history-sensitive merging, and delegates trust functions to client-side RSA certificates. %prep %setup -q %build %configure --with-bundled-lua=no --with-bundled-sqlite=%{bundled_sqlite} make %{?_smp_mflags} %check make %{?_smp_mflags} check %install rm -rf %{buildroot} make install DESTDIR=%{buildroot} rm -f %{buildroot}/%{_infodir}/dir lispdir=%{buildroot}/%{_datadir}/emacs/site-lisp mkdir -p ${lispdir} %{__install} -c -m 0444 contrib/monotone.el ${lispdir}/monotone.el emacs -batch -f batch-byte-compile ${lispdir}/monotone.el %clean rm -rf %{buildroot} %post if [ $1 -eq 1 ] then /sbin/install-info %{_infodir}/monotone.info %{_infodir}/dir > /dev/null 2>&1 || : fi %postun if [ $1 -eq 0 ] then /sbin/install-info --delete %{_infodir}/monotone.info %{_infodir}/dir > /dev/null 2>&1 || : fi %files %defattr(-,root,root,-) %doc AUTHORS COPYING ChangeLog INSTALL NEWS README README.changesets UPGRADE %doc monotone.html %{_bindir}/monotone %{_infodir}/monotone.info* %{_mandir}/man1/monotone.1* %{_datadir}/emacs/site-lisp/monotone.el* %changelog * Mon Jul 18 2005 Roland McGrath - 0.21-1 - Updated for 0.21 release. - Install Emacs support. * Thu Jul 7 2005 Roland McGrath - 0.20-0.1 - Updated for 0.20 release. - Added %%check section. - Cannot use FC4 native sqlite3, need newer bundled one. * Mon Apr 18 2005 Jeffrey C. Ollie - 0.18-0.4 - Modified summary so that it doesn't contain the name * Thu Apr 14 2005 Jeffrey C. Ollie - 0.18-0.3 - Modified install-info commands to prevent errors in case of --excludedocs * Wed Apr 13 2005 Jeffrey C. Ollie - 0.18-0.2 - Added post and postun scripts to take care of .info file - Added parallel make flags * Wed Apr 13 2005 Jeffrey C. Ollie - 0.18-0.1 - First version. From steve at silug.org Mon Jul 18 22:48:26 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 17:48:26 -0500 Subject: amavisd-new (was Re: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite) In-Reply-To: <1121718903.7652.3.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> Message-ID: <20050718224826.GA24864@osiris.silug.org> On Mon, Jul 18, 2005 at 10:35:02PM +0200, Nicolas Mailhot wrote: > You also need to submit perl-BerkeleyDB for amavis BTW (just in case you > forgot) I haven't. :-) For the record, the amavisd-new package is *not* ready. I do know about a couple of bugs (probably ones you noticed), plus I actually haven't gone back through your spec to see what else I might have missed (like I think you had sendmail milter support). Most of the time I spent on it so far was just finding all of the random dependencies (and packaging the ones that haven't been already). 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 Nicolas.Mailhot at laPoste.net Mon Jul 18 22:57:22 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 19 Jul 2005 00:57:22 +0200 Subject: amavisd-new (was Re: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite) In-Reply-To: <20050718224826.GA24864@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> <20050718224826.GA24864@osiris.silug.org> Message-ID: <1121727443.24363.1.camel@rousalka.dyndns.org> Le lundi 18 juillet 2005 ? 17:48 -0500, Steven Pritchard a ?crit : > On Mon, Jul 18, 2005 at 10:35:02PM +0200, Nicolas Mailhot wrote: > > You also need to submit perl-BerkeleyDB for amavis BTW (just in case you > > forgot) > > I haven't. :-) > > For the record, the amavisd-new package is *not* ready. I know. T'was just a bit too tempting to test it :) It's not ready, but it's not horrific either. I've seen worse. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From steve at silug.org Mon Jul 18 23:01:02 2005 From: steve at silug.org (Steven Pritchard) Date: Mon, 18 Jul 2005 18:01:02 -0500 Subject: amavisd-new (was Re: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite) In-Reply-To: <1121727443.24363.1.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> <20050718224826.GA24864@osiris.silug.org> <1121727443.24363.1.camel@rousalka.dyndns.org> Message-ID: <20050718230102.GA25303@osiris.silug.org> On Tue, Jul 19, 2005 at 12:57:22AM +0200, Nicolas Mailhot wrote: > T'was just a bit too tempting to test it :) I'm glad you are that interested. :-) > It's not ready, but it's not horrific either. I've seen worse. Well that makes me feel good... ;-) 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 tcallawa at redhat.com Mon Jul 18 23:35:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Jul 2005 18:35:23 -0500 Subject: Request for Review: Rekall and dependencies In-Reply-To: <20050714152252.GB10688@lisas.de> References: <1119238318.11411.8.camel@localhost.localdomain> <20050710165355.GA16609@lisas.de> <1121023144.22400.57.camel@localhost.localdomain> <20050714152252.GB10688@lisas.de> Message-ID: <1121729723.32518.41.camel@localhost.localdomain> On Thu, 2005-07-14 at 17:22 +0200, Adrian Reber wrote: > readline-devel is also required as BR Fixed. New spec and SRPM: SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-3.src.rpm SPEC: http://auroralinux.org/people/spot/review/xbsql.spec Once more (with feeling), please review/approve. ;) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Mon Jul 18 23:44:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Jul 2005 18:44:45 -0500 Subject: Please review: monotone In-Reply-To: <20050718224409.10AE02207D3@magilla.sf.frob.com> References: <20050718224409.10AE02207D3@magilla.sf.frob.com> Message-ID: <1121730285.32518.50.camel@localhost.localdomain> On Mon, 2005-07-18 at 15:44 -0700, Roland McGrath wrote: > Ok, let's get this show on the road. There are several of us who have > proposed monotone rpms. I haven't heard anything like a clear approval, > and I can't figure out who it is who ought to be stepping forward to do > that. I would be happy to be the maintainer, as probably would each other > who has proposed it. I'm ready to go right now if I can figure out what > constitutes proper approval. > > monotone 0.21 was just released, and it builds out of the box on FC4 and on > rawhide. Below is my current version of the spec file. I've added the > emacs support to the rpm. I'll probably keep tweaking it, and may add some > other stuff to make it simpler to run a monotone netsync server. This > works just fine as it is. Someone please tell me to commit it already. Review: Good: - rpmlint checks return nothing - name is fine - meets PackagingGuidelines - license ok (GPL), license matches source, COPYING included - spec is in am. english, legible - sources match upstream (I presume, since you only gave us a spec) - package compiles fine on fc4 (x86) - no extra BR, no missing BR - no locales - no shared/static libs - package is not relocatable - owns all directories that it creates - no duplicate files - file permissions ok - %clean ok - macro use is consistent - code not content - nothing in %doc affects runtime - no need for -docs, -devel APPROVED. Commit this thing into CVS already. ;) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue Jul 19 00:11:40 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Jul 2005 19:11:40 -0500 Subject: Request for review: smeg (Simple menu editor gnome) & pyxdg In-Reply-To: <1117643254.26609.2.camel@localhost.localdomain> References: <1117503506.16959.10.camel@localhost.localdomain> <1117643254.26609.2.camel@localhost.localdomain> Message-ID: <1121731900.32518.70.camel@localhost.localdomain> On Wed, 2005-06-01 at 18:27 +0200, Sindre Pedersen Bjordal wrote: > http://foolish.digitalinc.info/pakker/SRPMS/smeg.spec > http://foolish.digitalinc.info/pakker/SRPMS/smeg-0.7.1-1.src.rpm > > http://foolish.digitalinc.info/pakker/SRPMS/pyxdg.spec > http://foolish.digitalinc.info/pakker/SRPMS/pyxdg-0.13-1.src.rpm > > Updated smeg to 0.7.1, discovered a missing dep (gnome-python2-gconf) > > Updated pyxdg to 0.13 as smeg requires it. Review: pyxdg (reviewed pyxdg-0.14-2) Good: - rpmlint checks return nothing - meets naming guidelines (pyxdg is ok) - meets PackagingGuidelines - License OK (LGPL), matches source, text of license included - spec is in am.english, legible - sources match upstream - package builds ok on FC4 (x86) - no unnecessary BuildRequires, no missing BuildRequires - no locales - no shared library files - no -docs, no -devel - not relocatable - owns all directories it creates - no duplicate files - %clean ok - macro use is consistent APPROVED Review: smeg (reviewed smeg-0.7.5-2) Bad: - Should be BuildArch: noarch (nothing is actually compiled here) - Doesn't need CFLAGS passed at build time Good: - rpmlint errors: E: smeg only-non-binary-in-usr-lib (no worries, this is python) - naming is ok - meets PackagingGuidelines - License ok (GPL), matches actual code, text included in %doc - spec in am. english, legible - source matches upstream - package builds and runs ok on FC4 (x86) - no missing or forbidden BR - no shared libs - no -docs, -devel - no locales - not relocatable - owns all directories it creates - no duplicate files - macro use consistent - file attribs ok - code, not content The blocker on smeg is minor, and easily resolved, so I'm marking this APPROVED. Please make this package noarch without CFLAGS before you request a build. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue Jul 19 00:26:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Jul 2005 19:26:51 -0500 Subject: Sponsor and review request: opendap, librx --> *and* NCO review request In-Reply-To: <1119201019.9216.71.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1119154931.10309.8.camel@localhost.localdomain> <1119201019.9216.71.camel@ernie> Message-ID: <1121732811.32518.88.camel@localhost.localdomain> On Sun, 2005-06-19 at 13:10 -0400, Ed Hill wrote: > Heres the latest version: > > http://mitgcm.org/eh3/fedora_misc/nco.spec > http://mitgcm.org/eh3/fedora_misc/nco-3.0.1-1.src.rpm > > which is everything from the previous submissions plus an update to the > latest stable version (3.0.1) plus a comment about the eventual use of > opendap-devel. I tested it on both FC3 and FC4 so it appears to be > ready for a (hopefully final?) review. Review: (nco-3.0.1-1) Bad: - Missing COPYING as %doc (you can find it in doc/) Good: - rpmlint checks return: W: nco-devel no-documentation (safe to ignore) - naming is ok - meets PackagingGuidelines - license ok (GPL), matches code, but not in package? - spec in am. english, legible - source matches upstream (cvs co, looks ok) - package compiles ok on FC4 (x86) - no missing, forbidden items as BR - no locales - post/postun ok - not relocatable - owns all dirs it creates - no duplicate files - permissions set ok - %clean ok - no need for -docs - macro use is consistent - code not content - nothing in %doc affects runtime - headers/static libs in -devel - no .pc files - no suffixed libs - devel package properly requires base package - no .la files Really minor issue of the license file text is the only blocker, please fix it before you request a build. APPROVED. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From derrick_moser at yahoo.com Tue Jul 19 01:55:54 2005 From: derrick_moser at yahoo.com (Derrick Moser) Date: Tue, 19 Jul 2005 02:55:54 +0100 (BST) Subject: Sponsor request and ownership claim: iiimf-le-simplehangul Message-ID: <20050719015554.69375.qmail@web54106.mail.yahoo.com> Hello, I am the original author of simplehangul and would like to take over maintainership of the iiimf-le-simplehangul package. I have just created an account and am in need of a sponsor for membership in the cvsextras group. Cheers, Derrick Send instant messages to your online friends http://uk.messenger.yahoo.com From rc040203 at freenet.de Tue Jul 19 04:27:39 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 Jul 2005 06:27:39 +0200 Subject: Please review: monotone In-Reply-To: <1121730285.32518.50.camel@localhost.localdomain> References: <20050718224409.10AE02207D3@magilla.sf.frob.com> <1121730285.32518.50.camel@localhost.localdomain> Message-ID: <1121747260.9234.72.camel@mccallum.corsepiu.local> On Mon, 2005-07-18 at 18:44 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-07-18 at 15:44 -0700, Roland McGrath wrote: > > Ok, let's get this show on the road. There are several of us who have > > proposed monotone rpms. I haven't heard anything like a clear approval, > > and I can't figure out who it is who ought to be stepping forward to do > > that. I would be happy to be the maintainer, as probably would each other > > who has proposed it. I'm ready to go right now if I can figure out what > > constitutes proper approval. > > > > monotone 0.21 was just released, and it builds out of the box on FC4 and on > > rawhide. Below is my current version of the spec file. I've added the > > emacs support to the rpm. I'll probably keep tweaking it, and may add some > > other stuff to make it simpler to run a monotone netsync server. This > > works just fine as it is. Someone please tell me to commit it already. > > Review: > > Good: ... > APPROVED. Commit this thing into CVS already. ;) Hmm, the package seems to be using a modified, local, static copy of sqlite3. In the past, this kind of approach has caused serious vulnerabilities and maintenance problems (c.f. libz). Ralf From wtogami at redhat.com Tue Jul 19 05:56:17 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Jul 2005 19:56:17 -1000 Subject: Sponsor request and ownership claim: iiimf-le-simplehangul In-Reply-To: <20050719015554.69375.qmail@web54106.mail.yahoo.com> References: <20050719015554.69375.qmail@web54106.mail.yahoo.com> Message-ID: <42DC9601.8000300@redhat.com> Derrick Moser wrote: > Hello, > > I am the original author of simplehangul and would > like to take over maintainership of the > iiimf-le-simplehangul package. > > I have just created an account and am in need of a > sponsor for membership in the cvsextras group. > Does your new upstream version work with both FC3 and FC4, or it is a fork that works only with FC4's IIIMF directory layout and API? Just curious. I have approved your membership because I don't want to maintain this anymore (I don't use IIIMF anymore personally, and I also no longer study Korean language) and it makes a lot more sense for the upstream author to do so. http://fedoraproject.org/wiki/Extras Please be sure to read and follow the guidelines here when making changes to your package, and respect package ownership (don't touch packages not owned by you). If you are unsure about proper packaging procedure, you may request a review from the list by providing a URL to a .src.rpm or pointing at the CVS. Warren Togami wtogami at redhat.com From roland at redhat.com Tue Jul 19 07:24:01 2005 From: roland at redhat.com (Roland McGrath) Date: Tue, 19 Jul 2005 00:24:01 -0700 (PDT) Subject: Please review: monotone In-Reply-To: Ralf Corsepius's message of Tuesday, 19 July 2005 06:27:39 +0200 <1121747260.9234.72.camel@mccallum.corsepiu.local> Message-ID: <20050719072401.DCD5F230010@magilla.sf.frob.com> > Hmm, the package seems to be using a modified, local, static copy of > sqlite3. In the past, this kind of approach has caused serious > vulnerabilities and maintenance problems (c.f. libz). Unfortunately that's how they do it upstream. I had hoped that moving to sqlite 3.2.2 would mean we could use the system one, but that doesn't work because the monotone folks are actually using a locally modified version. I agree that's unwise and a maintenance problem, but it's an upstream problem. Their sqlite copy is part of their source that they maintain, so I don't worry about it any more than the rest of their source. Thanks, Roland From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 19 07:50:08 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jul 2005 09:50:08 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <1121523413.17248.4.camel@shuttle.273piedmont.com> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> Message-ID: <20050719095008.05624cac@python2> Brian Pepple wrote : > On Thu, 2005-07-14 at 21:21 +0200, Matthias Saou wrote: > > Well, in that case, I'd be interested in hearing your comments regarding > > the possibility of having a "gkrellm-xmms" package that would obsolete > > "gkrellmms". You can find such a package next to the "gkrellm-bmp" one. A > > quick review of both would be much appreciated too ;-) > > > > The specs look ok, but [...] Care to post a review? Still waiting for one :-) gkrellm-xmms & gkrellm-bmp : http://ftp.es6.freshrpms.net/tmp/extras/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.27 0.29 0.17 From paul at city-fan.org Tue Jul 19 09:24:03 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 19 Jul 2005 10:24:03 +0100 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718175303.GA18769@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> Message-ID: <42DCC6B3.3070909@city-fan.org> Steven Pritchard wrote: > On Mon, Jul 18, 2005 at 04:26:04PM +0100, Paul Howarth wrote: > >>Bad: >>- missing BuildRequires (from Makefile.PL): >> perl(Net::DNS) >= 0.46, > > > Since I'm not doing "make test", this isn't a build requirement. > > That said, the version isn't getting picked up automatically, so I'll > fix that. > > >> perl(Net::CIDR::Lite) >= 0.15, > > > Ditto. OK. >> perl(Sys::Hostname::Long) >= 1.0 > > > Again, it's not really a build requirement, because we're not doing > "make test". > > Besides, that's an optional module. > > 250 eval { require Sys::Hostname::Long }; > 251 $query->{myhostname} = $@ ? hostname() : Sys::Hostname::Long::hostname_long(); > > >> the latter is not yet included in Extras or up for review > > > All that said, I don't mind whipping up a package for it... Please do, because as Nicolas noted, the result of not doing so is horrible things in the maillog if you're a spamassassin user. If that's done, it'd also be nice to add perl(Sys::Hostname::Long) >= 1.0 as a Requires: >>- rpmlint output not empty, due to permissions issues on and in the >>samples directory. I'd fix the 2755 permission on the samples directory >>itself but wouldn't worry about the non-executable scripts in there >>(which are %%doc files) > > > 2755? The directory looks right to me. > > drwxr-xr-x 2 root root 0 Apr 26 2004 /usr/share/doc/perl-Mail-SPF-Query-1.997/sample This happened because the system I built the package on has sgid homedirs (where my build area is). It won't happen in the extras buildsystem, but you could fix it anyway if you wanted by setting the fourth parameter to "0755" in the defattr() macro in the files section. >>I'd like to see spfd and spfquery brought into the alternatives system. >>This is because there are other implementations of these (e.g. in libspf >>and libspf2, both of which I hope to include in extras when they're >>ready), and it would be useful to be able to install them in parallel >>with this package. > > > Maybe they should just be included as %doc? I don't have any strong > feelings about them being in $PATH. Maybe other users of the module might like them to be there though? Paul. From kaboom at oobleck.net Tue Jul 19 10:04:40 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 19 Jul 2005 06:04:40 -0400 (EDT) Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> Message-ID: On Mon, 18 Jul 2005, Ali Erdin? K?ro?lu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > I would like to prepare Clamav, Amavisd-new, Pyzor, DCC and Dansguardian packages > so is there any maintainer for them? if not I want to take the responsibility. DCC and Dansguardian are not free software later, chris From adrian at lisas.de Tue Jul 19 11:20:36 2005 From: adrian at lisas.de (Adrian Reber) Date: Tue, 19 Jul 2005 13:20:36 +0200 Subject: New version of libcdio Message-ID: <20050719112036.GA532@lisas.de> I have updated libcdio to 0.75. This, however, requires a recompile of applications depending on it. Currently in Extras this is only libcddb. I justed wanted to announce this change in case any external repository depends on libcdio. I will request a build for the devel branch in the next hours. Adrian From chris at chrisgrau.com Tue Jul 19 14:11:01 2005 From: chris at chrisgrau.com (Chris Grau) Date: Tue, 19 Jul 2005 07:11:01 -0700 Subject: Request for review / approval: frotz. In-Reply-To: <20050708172425.GA31553@chrisgrau.com> References: <20050708172425.GA31553@chrisgrau.com> Message-ID: <20050719141101.GD31746@chrisgrau.com> On Fri, Jul 08, 2005 at 10:24:25AM -0700, Chris Grau wrote: > This is my first attempt at submitting a package to Fedora Extras. I > hope I'm going about it the right way. > > Name: frotz > > Summary: Interpreter for Infocom and other Z-machine games > > Description: > > Frotz is an interpreter for Infocom games and other Z-machine games. > It complies with standard 1.0 of Graham Nelson's specification. > > http://www.chrisgrau.com/packages/frotz/frotz.spec > http://www.chrisgrau.com/packages/frotz/frotz-2.43-1.src.rpm Just a quick ping to see if anyone is interested in this package. I know it's just a game interpreter, so it probably has a low priority with most people. However, I realized that I did not include enough information to try out this package for people unfamiliar with it. To that end, I've added a pointer in the %description to the canonical interactive fiction web site to get more information and download free game files. Here are the updated files: http://www.chrisgrau.com/packages/frotz/frotz.spec http://www.chrisgrau.com/packages/frotz/frotz-2.43-2.fc4.cdg.src.rpm To make testing easier, I'm providing a short list of some games that I (and others in general) rather enjoyed. The Dreamhold, a tutorial adventure by Andrew Plotkin. http://www.ifarchive.org/if-archive/games/zcode/dreamhold.z8 Anchorhead: an Interactive Tale of Lovecraftian Horror, by Michael S. Gentry http://www.ifarchive.org/if-archive/games/zcode/anchor.z8 Curses, An Interactive Diversion by Graham Nelson http://www.ifarchive.org/if-archive/games/zcode/curses.z5 Risorgimento Represso, an Interactive Invigoration http://www.ifarchive.org/if-archive/games/zcode/risorg.z8 Also, if I understand the protocol correctly, I think I need to ask (beg?) for a sponsor as well. Thanks. -chris From tcallawa at redhat.com Tue Jul 19 14:58:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Jul 2005 09:58:33 -0500 Subject: Request for review / approval: frotz. In-Reply-To: <20050719141101.GD31746@chrisgrau.com> References: <20050708172425.GA31553@chrisgrau.com> <20050719141101.GD31746@chrisgrau.com> Message-ID: <1121785113.32518.110.camel@localhost.localdomain> On Tue, 2005-07-19 at 07:11 -0700, Chris Grau wrote: > Here are the updated files: > > http://www.chrisgrau.com/packages/frotz/frotz.spec > http://www.chrisgrau.com/packages/frotz/frotz-2.43-2.fc4.cdg.src.rpm Review: frotz Good: - rpmlint checks return nothing - naming OK - meets PackagingGuidelines - License OK (GPL), matches code, text of license in %doc - source matches upstream - package compiles, builds, runs on FC4 (x86) - no locales - spec is legible, in am. english - no excluded BR, no missing BR - no shared/static libraries - no -devel/-docs - not relocatable - owns all directories it creates - file attribs ok - no duplicate files - %clean OK - macro use is consistent - code, not content - nothing in %doc affects runtime APPROVED. Very good first package. :) Now, what you need to do is go ahead and get an account here: https://admin.fedora.redhat.com/accounts/ When your paperwork is in, I'll sponsor you. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From byte at aeon.com.my Tue Jul 19 14:56:49 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 19 Jul 2005 10:56:49 -0400 Subject: Request for review: ngrep Message-ID: <1121785009.3251.97.camel@potter.soho.bytebot.net> ngrep is grep command that works on realtime network data. It makes use of libpcap, and is a rather useful utility to have around. There's also a fairly basic introduction to it at http://software.newsforge.com/software/05/07/08/164249.shtml?tid=91 Spec file: http://www.bytebot.net/rpms/ngrep/ngrep.spec SRPM, RPM (i386) at: http://www.bytebot.net/rpms/ngrep/ Builds/works fine in FC-4, with the only real requirement being libpcap rpmlint whinges about upstream CVS/ directory in the docs folder, but otherwise all seems well Approval? -- Colin Charles, http://www.bytebot.net/ From lmacken at redhat.com Tue Jul 19 15:00:48 2005 From: lmacken at redhat.com (Luke Macken) Date: Tue, 19 Jul 2005 11:00:48 -0400 Subject: Request for Review: nethack In-Reply-To: <20050710233820.GA4963@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> Message-ID: <20050719150048.GA5200@tomservo.boston.redhat.com> On Sun, Jul 10, 2005 at 07:38:20PM -0400, Luke Macken wrote: | I noticed that we only have a graphical nethack version in extras | (falconseye), which does not come close to satisfying my ASCII dungeon | cravings. So I decided to package up the game that almost caused me to | fail out of college, NetHack. | | - - - | Description: | NetHack is a single player dungeon exploration game that runs on a | wide variety of computer systems, with a variety of graphical and text | interfaces all using the same game engine. | | Unlike many other Dungeons & Dragons-inspired games, the emphasis in | NetHack is on discovering the detail of the dungeon and not simply | killing everything in sight - in fact, killing everything in sight is | a good way to die quickly. | | Each game presents a different landscape - the random number generator | provides an essentially unlimited number of variations of the dungeon | and its denizens to be discovered by the player in one of a number of | characters: you can pick your race, your role, and your gender. | - - - | | SPEC: http://people.redhat.com/lmacken/nethack.spec | SRPM: http://people.redhat.com/lmacken/nethack-3.4.3-1.src.rpm So, anyone care to review/approve this so I import it into CVS ? thanks, luke From bugs.michael at gmx.net Tue Jul 19 15:12:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jul 2005 17:12:33 +0200 Subject: packages for review: openbox and friends In-Reply-To: References: <20050420052915.GA11961@lisas.de> Message-ID: <20050719171233.2bb8e1ca.bugs.michael@gmx.net> On Wed, 20 Apr 2005 08:12:35 -0400 (EDT), Chris Ricker wrote: > > > openbox-3.2-5: * Fails to build here: Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/qa/tmp/rpm/tmp/openbox-3.2-5-root-qa error: Installed (but unpackaged) file(s) found: /usr/share/openbox/themeupdate.pyc /usr/share/openbox/themeupdate.pyo * Suggest adding "BuildRequires: gettext". checking whether NLS is requested... yes checking for msgfmt... no checking for gmsgfmt... : checking for xgettext... no checking for msgmerge... no * Does "Conflicts: fluxbox <= 0:0.1.14" affect current fluxbox 0.9.x in Extras? What kind of conflict was this? * In %files section, %{_datadir}/openbox/ and %{_sysconfdir}/xdg/openbox/ are not included. * GPL not included in %doc. [...] obpager-1.8-1: * Had to look up http://dl.sf.net/obpager/obpager-1.8.tar.gz manually, since Source0 is not an URL. * %attr(...) usage most likely not necessary. * GPL not included in %doc (warning: file COPYING is +x) [...] obconf-1.5-1: * Had to look up http://icculus.org/openbox/obconf/obconf-1.5.tar.gz manually, since Source0 is not an URL. * %attr(...) usage most likely not necessary. * GPL not included in %doc. * hint: desktop-file-install has option --delete-original, so you could drop the extra rm -f ... * Directory %{_datadir}/obconf/ not included. From bugs.michael at gmx.net Tue Jul 19 15:30:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jul 2005 17:30:55 +0200 Subject: Request for review / approval: frotz. In-Reply-To: <1121785113.32518.110.camel@localhost.localdomain> References: <20050708172425.GA31553@chrisgrau.com> <20050719141101.GD31746@chrisgrau.com> <1121785113.32518.110.camel@localhost.localdomain> Message-ID: <20050719173055.35e92406.bugs.michael@gmx.net> On Tue, 19 Jul 2005 09:58:33 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-07-19 at 07:11 -0700, Chris Grau wrote: > > > Here are the updated files: > > > > http://www.chrisgrau.com/packages/frotz/frotz.spec > > http://www.chrisgrau.com/packages/frotz/frotz-2.43-2.fc4.cdg.src.rpm > > Review: frotz > > Good: > > - rpmlint checks return nothing > - naming OK > - meets PackagingGuidelines > - License OK (GPL), matches code, text of license in %doc > - source matches upstream > - package compiles, builds, runs on FC4 (x86) > - no locales > - spec is legible, in am. english > - no excluded BR, no missing BR > - no shared/static libraries > - no -devel/-docs > - not relocatable > - owns all directories it creates > - file attribs ok > - no duplicate files > - %clean OK > - macro use is consistent > - code, not content > - nothing in %doc affects runtime > > APPROVED. Very good first package. :) > > Now, what you need to do is go ahead and get an account here: > https://admin.fedora.redhat.com/accounts/ > > When your paperwork is in, I'll sponsor you. > > ~spot Two hints here: : %build : sed -e "s/@@OPTS@@/$RPM_OPT_FLAGS/" Makefile > Makefile.tmp : mv Makefile.tmp Makefile sed -i (of at least FC2) can substitute in a file directly: sed -i -e "s/@@OPTS@@/$RPM_OPT_FLAGS/" Makefile : make %{?_smp_mflags} : gzip doc/frotz.6 Compressing manual pages manually is not necessary. rpmbuild does this automatically. %{_mandir}/man6/frotz.6* in %files section then. These may need investigation: src/curses/ux_text.c: In function 'os_display_char': src/curses/ux_text.c:209: warning: comparison is always true due to limited range of data type src/curses/ux_text.c: In function 'os_char_width': src/curses/ux_text.c:280: warning: comparison is always true due to limited range of data type From ville.skytta at iki.fi Tue Jul 19 15:29:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 19 Jul 2005 18:29:25 +0300 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <42DCC6B3.3070909@city-fan.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> Message-ID: <1121786965.14525.96.camel@localhost.localdomain> On Tue, 2005-07-19 at 10:24 +0100, Paul Howarth wrote: > Steven Pritchard wrote: > >> perl(Sys::Hostname::Long) >= 1.0 > > > > Again, it's not really a build requirement, because we're not doing > > "make test". > > > > Besides, that's an optional module. > > > > 250 eval { require Sys::Hostname::Long }; > > 251 $query->{myhostname} = $@ ? hostname() : Sys::Hostname::Long::hostname_long(); > > > >> the latter is not yet included in Extras or up for review > > > > All that said, I don't mind whipping up a package for it... > > Please do, because as Nicolas noted, the result of not doing so is > horrible things in the maillog if you're a spamassassin user. If that's > done, it'd also be nice to add perl(Sys::Hostname::Long) >= 1.0 as a > Requires: On the other hand, if the log trashing only because of the two lines above (and/or other similar trivial things), patching it to just always use hostname() would be very easy. From nicolas.mailhot at laposte.net Tue Jul 19 15:37:40 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 19 Jul 2005 17:37:40 +0200 (CEST) Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121786965.14525.96.camel@localhost.localdomain> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> Message-ID: <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> On Mar 19 juillet 2005 17:29, Ville Skytt? wrote: > On Tue, 2005-07-19 at 10:24 +0100, Paul Howarth wrote: >> Steven Pritchard wrote: > >> >> perl(Sys::Hostname::Long) >= 1.0 >> > >> > Again, it's not really a build requirement, because we're not doing >> > "make test". >> > >> > Besides, that's an optional module. >> > >> > 250 eval { require Sys::Hostname::Long }; >> > 251 $query->{myhostname} = $@ ? hostname() : >> Sys::Hostname::Long::hostname_long(); >> > >> >> the latter is not yet included in Extras or up for review >> > >> > All that said, I don't mind whipping up a package for it... >> >> Please do, because as Nicolas noted, the result of not doing so is >> horrible things in the maillog if you're a spamassassin user. If that's >> done, it'd also be nice to add perl(Sys::Hostname::Long) >= 1.0 as a >> Requires: > > On the other hand, if the log trashing only because of the two lines > above (and/or other similar trivial things), patching it to just always > use hostname() would be very easy. Either way, it can't be uploaded as-is. The sa log trashing is terrible. -- Nicolas Mailhot From ville.skytta at iki.fi Tue Jul 19 15:40:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 19 Jul 2005 18:40:45 +0300 Subject: Request for Review: nethack In-Reply-To: <20050719150048.GA5200@tomservo.boston.redhat.com> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050719150048.GA5200@tomservo.boston.redhat.com> Message-ID: <1121787645.14525.105.camel@localhost.localdomain> On Tue, 2005-07-19 at 11:00 -0400, Luke Macken wrote: > | SPEC: http://people.redhat.com/lmacken/nethack.spec > | SRPM: http://people.redhat.com/lmacken/nethack-3.4.3-1.src.rpm > > So, anyone care to review/approve this so I import it into CVS ? A quick peek into the specfile, not a full review: Nobody has stepped up and wanted to continue maintaining nethack-falconseye, so I'd suggest removing the Conflicts, and adding a "Obsoletes: nethack-falconseye <= 1.9.4-6.a". You're listing stuff in the data dir as normal files, which would mean for example the "record" file being silently overwritten on upgrades. I'm pretty certain that people wouldn't like that at all ;). I don't remember what's stored in "perm" and "logfile", but those should be checked, too. My nethack-falconseye lists everything in the data dir as %config(noreplace) which isn't probably the prettiest solution, but at least it prevents the files from being overwritten on upgrades, and from removed (if modified) on erase. From nicolas.mailhot at laposte.net Tue Jul 19 15:52:43 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 19 Jul 2005 17:52:43 +0200 (CEST) Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> Message-ID: <52797.192.54.193.37.1121788363.squirrel@rousalka.dyndns.org> On Mar 19 juillet 2005 17:37, Nicolas Mailhot wrote: > > On Mar 19 juillet 2005 17:29, Ville Skytt? wrote: >> On Tue, 2005-07-19 at 10:24 +0100, Paul Howarth wrote: >>> Steven Pritchard wrote: >> >>> >> perl(Sys::Hostname::Long) >= 1.0 >>> > >>> > Again, it's not really a build requirement, because we're not doing >>> > "make test". >>> > >>> > Besides, that's an optional module. >>> > >>> > 250 eval { require Sys::Hostname::Long }; >>> > 251 $query->{myhostname} = $@ ? hostname() : >>> Sys::Hostname::Long::hostname_long(); >>> > >>> >> the latter is not yet included in Extras or up for review >>> > >>> > All that said, I don't mind whipping up a package for it... >>> >>> Please do, because as Nicolas noted, the result of not doing so is >>> horrible things in the maillog if you're a spamassassin user. If that's >>> done, it'd also be nice to add perl(Sys::Hostname::Long) >= 1.0 as a >>> Requires: >> >> On the other hand, if the log trashing only because of the two lines >> above (and/or other similar trivial things), patching it to just always >> use hostname() would be very easy. > > Either way, it can't be uploaded as-is. The sa log trashing is terrible. BTW you'll get the same kind of log trashing in rawhide sa if perl-Mail-SPF-Query is not installed, so I doubt it'll stay in extras for long. Seems it's a core dep now. Regards, -- Nicolas Mailhot From ryo-dairiki at mbm.nifty.com Tue Jul 19 15:56:15 2005 From: ryo-dairiki at mbm.nifty.com (Ryo Dairiki) Date: Wed, 20 Jul 2005 00:56:15 +0900 Subject: mplayer for FC4 x86_64? In-Reply-To: <1120147128.3714.32.camel@notebook.thl.home> References: <1120141323.2815.134.camel@localhost.localdomain> <1120147128.3714.32.camel@notebook.thl.home> Message-ID: <42DD229F.9050403@mbm.nifty.com> I've successed in compiling MPlayer on FC4 x86_64. Please download the SRPM from Freshrpms and use my specfile and patchfile. Freshrpms: http://stentz.freshrpms.net/rpm.html?id=251 My briefcase: http://briefcase.yahoo.co.jp/ryo_dairiki Notice: This is very * 4 draft one. I'll rewrite it later. Ryo Dairiki Thorsten Leemhuis wrote: >Am Donnerstag, den 30.06.2005, 16:33 +0200 schrieb Andreas Thienemann: > > >>On Thu, 30 Jun 2005, Ville Skytt? wrote: >> >> >> >>>>If you are so inclined, take the packages, rebuild them on your system and >>>>install em. >>>> >>>> >>>The problem is that mplayer build fails currently on FC4 x86_64, AFAIK >>>due to some asm "fun". >>> >>> >>Great. >> >>Try the i386 build. The ia32 emultation of the amd chip should manage >>fine. >> >> > >Mplayer needs a whole bunch of 32 libraries on an x86_64 arch then, too >-- and that is rather messy and was quite complicated last time I tried >it. > >For those interested in mplayer x86_64 CC to this bug: >http://bugzilla.livna.org/show_bug.cgi?id=499 > > > From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 19 16:24:10 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jul 2005 18:24:10 +0200 Subject: mplayer for FC4 x86_64? In-Reply-To: <42DD229F.9050403@mbm.nifty.com> References: <1120141323.2815.134.camel@localhost.localdomain> <1120147128.3714.32.camel@notebook.thl.home> <42DD229F.9050403@mbm.nifty.com> Message-ID: <20050719182410.31e1b0cd@python2> Ryo Dairiki wrote : > I've successed in compiling MPlayer on FC4 x86_64. > Please download the SRPM from Freshrpms and use my specfile and patchfile. Definitely the wrong list for this. Thanks nevertheless, I'll have a look and try out your patch, then hopefully put up an x86_64 build on freshrpms ;-) Matthias PS: Don't hesitate to send feedback/patches regarding packages on freshrpms.net directly to me or to the freshrpms-list. -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 1.30 1.33 1.24 From byte at aeon.com.my Tue Jul 19 15:37:38 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 19 Jul 2005 11:37:38 -0400 Subject: Request for review: ngrep In-Reply-To: <1121785009.3251.97.camel@potter.soho.bytebot.net> References: <1121785009.3251.97.camel@potter.soho.bytebot.net> Message-ID: <1121787458.3251.102.camel@potter.soho.bytebot.net> On Tue, 2005-07-19 at 10:56 -0400, Colin Charles wrote: > ngrep is grep command that works on realtime network data. On second thought, reading LICENSE.txt seems a little alarming... -- Colin Charles, http://www.bytebot.net/ From steve at silug.org Tue Jul 19 16:28:08 2005 From: steve at silug.org (Steven Pritchard) Date: Tue, 19 Jul 2005 11:28:08 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121786965.14525.96.camel@localhost.localdomain> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> Message-ID: <20050719162808.GA9145@osiris.silug.org> On Tue, Jul 19, 2005 at 06:29:25PM +0300, Ville Skytt? wrote: > On the other hand, if the log trashing only because of the two lines > above (and/or other similar trivial things), patching it to just always > use hostname() would be very easy. That's what I'm inclined to do. 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 paul at city-fan.org Tue Jul 19 16:36:14 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 19 Jul 2005 17:36:14 +0100 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050719162808.GA9145@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> <20050719162808.GA9145@osiris.silug.org> Message-ID: <42DD2BFE.60001@city-fan.org> Steven Pritchard wrote: > On Tue, Jul 19, 2005 at 06:29:25PM +0300, Ville Skytt? wrote: > >>On the other hand, if the log trashing only because of the two lines >>above (and/or other similar trivial things), patching it to just always >>use hostname() would be very easy. > > > That's what I'm inclined to do. Fine by me. Paul. From bugs.michael at gmx.net Tue Jul 19 16:48:13 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jul 2005 18:48:13 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050719095008.05624cac@python2> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> <20050719095008.05624cac@python2> Message-ID: <20050719184813.4eaaa3f8.bugs.michael@gmx.net> On Tue, 19 Jul 2005 09:50:08 +0200, Matthias Saou wrote: > Brian Pepple wrote : > > > On Thu, 2005-07-14 at 21:21 +0200, Matthias Saou wrote: > > > Well, in that case, I'd be interested in hearing your comments regarding > > > the possibility of having a "gkrellm-xmms" package that would obsolete > > > "gkrellmms". You can find such a package next to the "gkrellm-bmp" one. A > > > quick review of both would be much appreciated too ;-) > > > > > > > The specs look ok, but [...] > > Care to post a review? Still waiting for one :-) > > gkrellm-xmms & gkrellm-bmp : > http://ftp.es6.freshrpms.net/tmp/extras/ The "Conflicts" in there are unacceptable. gkrellm-xmms may obsolete and provide gkrellmms in the usual way. But gkrellm-bmp must not use the same file name for its plugin and locale files than gkrellm-xmms. If upstream doesn't like to rename the plugin, you could do it, e.g.: gkrellmms-bmp.so --- gkrellm-bmp.spec.orig 2005-07-19 18:40:43.000000000 +0200 +++ gkrellm-bmp.spec 2005-07-19 18:44:55.000000000 +0200 @@ -41,18 +41,21 @@ %{__make} install \ DESTDIR="%{buildroot}" \ PLUGIN_DIR="%{gkplugindir}" \ + PACKAGE="gkrellmms-bmp" \ enable_nls=1 -%find_lang gkrellmms +mv %{buildroot}%{gkplugindir}/gkrellmms.so \ + %{buildroot}%{gkplugindir}/gkrellmms-bmp.so +%find_lang gkrellmms-bmp %clean %{__rm} -rf %{buildroot} -%files -f gkrellmms.lang +%files -f gkrellmms-bmp.lang %defattr(-, root, root, 0755) %doc Changelog FAQ README -%{gkplugindir}/gkrellmms.so +%{gkplugindir}/gkrellmms-bmp.so %changelog From jspaleta at gmail.com Tue Jul 19 16:57:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 19 Jul 2005 12:57:30 -0400 Subject: New package: istanbul In-Reply-To: <1120057787.3221.12.camel@remedyz.boston.redhat.com> References: <1120055659.3221.6.camel@remedyz.boston.redhat.com> <1120056858.9519.92.camel@blaa> <1120057787.3221.12.camel@remedyz.boston.redhat.com> Message-ID: <604aa79105071909573d5b9e1b@mail.gmail.com> On 6/29/05, John (J5) Palmieri wrote: > A new spec and srpm is up with your suggestions added: > > SRPM: http://people.redhat.com/johnp/istanbul/istanbul-0.1.0-2.src.rpm > SPEC: http://people.redhat.com/johnp/istanbul/istanbul.spec is this still the latest attempt that you are looking to get approval for? where are you in terms of getting cvs access to extras? -jef From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 19 17:04:41 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jul 2005 19:04:41 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050719184813.4eaaa3f8.bugs.michael@gmx.net> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> <20050719095008.05624cac@python2> <20050719184813.4eaaa3f8.bugs.michael@gmx.net> Message-ID: <20050719190441.45a82553@python2> Michael Schwendt wrote : > The "Conflicts" in there are unacceptable. gkrellm-xmms may obsolete and > provide gkrellmms in the usual way. But gkrellm-bmp must not use the same > file name for its plugin and locale files than gkrellm-xmms. If upstream doesn't like to rename the plugin, you could do it, e.g.: gkrellmms-bmp.so Sure. Is the PACKAGE= override during "make install" enough to get the plugin to use the right translations, though? Seems surprising to me. Doesn't it also need it during the actual compile stage? Sorry if this seems like a silly question :-) Matthias > --- gkrellm-bmp.spec.orig 2005-07-19 18:40:43.000000000 +0200 > +++ gkrellm-bmp.spec 2005-07-19 18:44:55.000000000 +0200 > @@ -41,18 +41,21 @@ > %{__make} install \ > DESTDIR="%{buildroot}" \ > PLUGIN_DIR="%{gkplugindir}" \ > + PACKAGE="gkrellmms-bmp" \ > enable_nls=1 > -%find_lang gkrellmms > +mv %{buildroot}%{gkplugindir}/gkrellmms.so \ > + %{buildroot}%{gkplugindir}/gkrellmms-bmp.so > +%find_lang gkrellmms-bmp > > > %clean > %{__rm} -rf %{buildroot} > > > -%files -f gkrellmms.lang > +%files -f gkrellmms-bmp.lang > %defattr(-, root, root, 0755) > %doc Changelog FAQ README > -%{gkplugindir}/gkrellmms.so > +%{gkplugindir}/gkrellmms-bmp.so > > > %changelog -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 1.94 2.54 1.95 From Nicolas.Mailhot at laPoste.net Tue Jul 19 17:08:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 19 Jul 2005 19:08:07 +0200 Subject: Clamav, Amavisd-new, Pyzor, DCC and Dansguardian In-Reply-To: <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> References: <20050718140501.61dd0f6b.erdinc@prosoft.com.tr> <39863.192.54.193.37.1121674380.squirrel@rousalka.dyndns.org> Message-ID: <1121792887.14056.1.camel@rousalka.dyndns.org> Le lundi 18 juillet 2005 ? 10:13 +0200, Nicolas Mailhot a ?crit : > On Lun 18 juillet 2005 13:05, Ali Erdin? K?ro?lu wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi all, > > I would like to prepare Clamav, Amavisd-new, Pyzor, DCC and Dansguardian > > packages > > so is there any maintainer for them? if not I want to take the > > responsibility. > > clamav and pyzor (and razor, spamassassin) are already packaged. > > amavisd-new isn't but all deps should already be taken care of. The > difficult part is to automate cleanly clamav and MTA integration. > > Last time I checked DCC was not OSS and/or a bastard to package. > > Never looked at Dansguardian You can however work on dspam since amavis can use it too and it is FOSS. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Tue Jul 19 17:22:08 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jul 2005 19:22:08 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050719190441.45a82553@python2> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> <20050719095008.05624cac@python2> <20050719184813.4eaaa3f8.bugs.michael@gmx.net> <20050719190441.45a82553@python2> Message-ID: <20050719192208.03395d1a.bugs.michael@gmx.net> On Tue, 19 Jul 2005 19:04:41 +0200, Matthias Saou wrote: > Michael Schwendt wrote : > > > The "Conflicts" in there are unacceptable. gkrellm-xmms may obsolete and > > provide gkrellmms in the usual way. But gkrellm-bmp must not use the same > > file name for its plugin and locale files than gkrellm-xmms. If upstream doesn't like to rename the plugin, you could do it, e.g.: gkrellmms-bmp.so > > Sure. Is the PACKAGE= override during "make install" enough to get the > plugin to use the right translations, though? Seems surprising to me. > Doesn't it also need it during the actual compile stage? Sorry if this > seems like a silly question :-) Yes, also during %build. My cut'n'paste mistake. But it's not enough for both plugins to co-exist, unfortunately. :-/ $ gkrellm gkrellm segmentation fault: GkrellMMS (create_monitor) Aborted Apart from the same plugin name, they also share something else. From lmacken at redhat.com Tue Jul 19 17:26:50 2005 From: lmacken at redhat.com (Luke Macken) Date: Tue, 19 Jul 2005 13:26:50 -0400 Subject: Request for Review: nethack In-Reply-To: <1121787645.14525.105.camel@localhost.localdomain> References: <20050710233820.GA4963@tomservo.boston.redhat.com> <20050719150048.GA5200@tomservo.boston.redhat.com> <1121787645.14525.105.camel@localhost.localdomain> Message-ID: <20050719172650.GA5387@tomservo.boston.redhat.com> On Tue, Jul 19, 2005 at 06:40:45PM +0300, Ville Skytt? wrote: | On Tue, 2005-07-19 at 11:00 -0400, Luke Macken wrote: | > | SPEC: http://people.redhat.com/lmacken/nethack.spec | > | SRPM: http://people.redhat.com/lmacken/nethack-3.4.3-1.src.rpm | > | > So, anyone care to review/approve this so I import it into CVS ? | | A quick peek into the specfile, not a full review: | | Nobody has stepped up and wanted to continue maintaining | nethack-falconseye, so I'd suggest removing the Conflicts, and adding a | "Obsoletes: nethack-falconseye <= 1.9.4-6.a". Fixed. | You're listing stuff in the data dir as normal files, which would mean | for example the "record" file being silently overwritten on upgrades. | I'm pretty certain that people wouldn't like that at all ;). I don't | remember what's stored in "perm" and "logfile", but those should be | checked, too. My nethack-falconseye lists everything in the data dir as | %config(noreplace) which isn't probably the prettiest solution, but at | least it prevents the files from being overwritten on upgrades, and from | removed (if modified) on erase. Good call. Fixed. It looks like no one has any problems with this package being included in extras, so I'll go ahead an import it to CVS and wait for it to get APPROVED. luke From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 19 17:36:50 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jul 2005 19:36:50 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050719192208.03395d1a.bugs.michael@gmx.net> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> <20050719095008.05624cac@python2> <20050719184813.4eaaa3f8.bugs.michael@gmx.net> <20050719190441.45a82553@python2> <20050719192208.03395d1a.bugs.michael@gmx.net> Message-ID: <20050719193650.2c7cfd40@python2> Michael Schwendt wrote : [...] gkrellm-xmms and gkrellm-bmp build from the same sources [...] > Apart from the same plugin name, they also share something else. >From what I saw with the -DHAVE_BMP (from the top of my head), they seem to share pretty much everything except the external lib they link to, the string they display in gkrellm and the command they run by default. I assumed they wouldn't coexist peacefully (pretty much identical shared libs), which is why I went for the easy solution, the "Conflicts:" tags... Not sure if it's really useful to try and make them play nice together, given that they're for the same use, so asking users to install either but not both doesn't seem like such an odd thing to do. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.88 1.69 1.95 From ville.skytta at iki.fi Tue Jul 19 17:37:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 19 Jul 2005 20:37:32 +0300 Subject: Request for review: ngrep In-Reply-To: <1121787458.3251.102.camel@potter.soho.bytebot.net> References: <1121785009.3251.97.camel@potter.soho.bytebot.net> <1121787458.3251.102.camel@potter.soho.bytebot.net> Message-ID: <1121794652.14525.131.camel@localhost.localdomain> On Tue, 2005-07-19 at 11:37 -0400, Colin Charles wrote: > On Tue, 2005-07-19 at 10:56 -0400, Colin Charles wrote: > > ngrep is grep command that works on realtime network data. > > On second thought, reading LICENSE.txt seems a little alarming... To me it looks like it's just a BSDish one, with the additional requirement that modified versions must be clearly marked as such in the docs. The license certainly isn't GPL, though. But the license is incompatible with the GPL, which means it cannot be built/shipped using the GPL'd regex bundled with the sources. No problems when built with pcre, I think. I have a local package of this too, in which I've "modified" ngrep to link with the system pcre, and added a brief README about it (which should be enough to satisfy the license). Feel free to borrow what you find useful: http://cachalot.mine.nu/4/SRPMS/ngrep-1.44-0.1.src.rpm From jspaleta at gmail.com Tue Jul 19 17:37:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 19 Jul 2005 13:37:04 -0400 Subject: New package: istanbul In-Reply-To: <1120057787.3221.12.camel@remedyz.boston.redhat.com> References: <1120055659.3221.6.camel@remedyz.boston.redhat.com> <1120056858.9519.92.camel@blaa> <1120057787.3221.12.camel@remedyz.boston.redhat.com> Message-ID: <604aa79105071910375dbea9da@mail.gmail.com> On 6/29/05, John (J5) Palmieri wrote: > A new spec and srpm is up with your suggestions added: > > SRPM: http://people.redhat.com/johnp/istanbul/istanbul-0.1.0-2.src.rpm > SPEC: http://people.redhat.com/johnp/istanbul/istanbul.spec Niether the istanbul-0.1.0-2 and istanbul-0.1.1-1 from that directory is building against the fedora core development tree for me inside mock. mock's build log contains: checking for GTK... configure: error: Python headers missing error: Bad exit status from /var/tmp/rpm-tmp.23171 (%build) It looks like you need to add a BuildRequires for gtk2-devel and python-devel to the spec. Once I add those 2 BuildRequires mock build goes through against the fedora development tree. -jef From bugs.michael at gmx.net Tue Jul 19 17:55:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jul 2005 19:55:59 +0200 Subject: Request for review : gkrellm-bmp In-Reply-To: <20050719193650.2c7cfd40@python2> References: <20050713231519.7d4d0870@python2> <1121294582.3432.1.camel@shuttle.273piedmont.com> <20050714212139.296a473d@python2> <1121523413.17248.4.camel@shuttle.273piedmont.com> <20050719095008.05624cac@python2> <20050719184813.4eaaa3f8.bugs.michael@gmx.net> <20050719190441.45a82553@python2> <20050719192208.03395d1a.bugs.michael@gmx.net> <20050719193650.2c7cfd40@python2> Message-ID: <20050719195559.1f5d3acf.bugs.michael@gmx.net> On Tue, 19 Jul 2005 19:36:50 +0200, Matthias Saou wrote: > Michael Schwendt wrote : > > [...] gkrellm-xmms and gkrellm-bmp build from the same sources [...] > > > Apart from the same plugin name, they also share something else. > > >From what I saw with the -DHAVE_BMP (from the top of my head), they seem > to share pretty much everything except the external lib they link to, the > string they display in gkrellm and the command they run by default. I > assumed they wouldn't coexist peacefully (pretty much identical shared > libs), which is why I went for the easy solution, the "Conflicts:" tags... > > Not sure if it's really useful to try and make them play nice together, > given that they're for the same use, so asking users to install either but > not both doesn't seem like such an odd thing to do. Other package conflicts were not permitted either. E.g. Sylpheed and Sylpheed-Claws. All package conflicts are bad as they are ugly to deal with in package tools. Where "user == admin of a single-user system", it may not be a problem. But whereas you can install XMMS and BMP at once in multi-user environments, you could not do the same with the GKrellm plugins. It's possible to rename all "gkrellmms_" symbols in the *.c/*.h files to "gkrellmms_bmp_". But there's no guarantee this will still work as easily in the future. The plugins also share the same name "GKrellMMS", so inside GKrellm preferences you cannot see whether you look at the XMMS or BMP plugin. This is less than ideal, too. From jspaleta at gmail.com Tue Jul 19 18:27:51 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 19 Jul 2005 14:27:51 -0400 Subject: New package: istanbul In-Reply-To: <604aa79105071910375dbea9da@mail.gmail.com> References: <1120055659.3221.6.camel@remedyz.boston.redhat.com> <1120056858.9519.92.camel@blaa> <1120057787.3221.12.camel@remedyz.boston.redhat.com> <604aa79105071910375dbea9da@mail.gmail.com> Message-ID: <604aa79105071911273347b3f8@mail.gmail.com> On 7/19/05, Jeff Spaleta wrote: > It looks like you need to add a BuildRequires for gtk2-devel and > python-devel to the spec. Once I add those 2 BuildRequires mock build > goes through against the fedora development tree. Here is the srpm and binary package output from mock along with the spec file which includes the modifications I made to get this to build against the fedora development tree. According to the requirements specified previously by j5 this won't build against fc4 or earlier unless some dependancies are updated in core. I can't comment if those are overstrict requirements or not. http://jef.is-a-geek.com/downloads/istanbul/ rpmlint output from the mock built binary: E: istanbul description-line-too-long Istanbul is a desktop session recorder. You can use it to record your desktop session and then play it back for demos, tutorials and presentations. Sessions are recorded to ogg theora files for later playback. E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/README E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/AUTHORS E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/NEWS W: istanbul empty-%post W: istanbul empty-%postun Not sure if there needs to be a post or postun scriptlet. J5 would probably have to comment. I'm just providing these packages to fix the mock build problems. I can't comment on anything that isnt a glaring build error. Im assuming J5 i still interested in maintaining this as part of extras. -jef From chris at chrisgrau.com Tue Jul 19 18:39:50 2005 From: chris at chrisgrau.com (Chris Grau) Date: Tue, 19 Jul 2005 11:39:50 -0700 Subject: Request for review / approval: frotz. In-Reply-To: <1121785113.32518.110.camel@localhost.localdomain> References: <20050708172425.GA31553@chrisgrau.com> <20050719141101.GD31746@chrisgrau.com> <1121785113.32518.110.camel@localhost.localdomain> Message-ID: <20050719183950.GC21103@chrisgrau.com> On Tue, Jul 19, 2005 at 09:58:33AM -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-07-19 at 07:11 -0700, Chris Grau wrote: > > > Here are the updated files: > > > > http://www.chrisgrau.com/packages/frotz/frotz.spec > > http://www.chrisgrau.com/packages/frotz/frotz-2.43-2.fc4.cdg.src.rpm > > Review: frotz > > Good: [snipped review details] > > APPROVED. Very good first package. :) Thanks. :) > Now, what you need to do is go ahead and get an account here: > https://admin.fedora.redhat.com/accounts/ Done. > When your paperwork is in, I'll sponsor you. Thanks again. -chris From johnp at redhat.com Tue Jul 19 18:42:28 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 19 Jul 2005 14:42:28 -0400 Subject: New package: istanbul In-Reply-To: <604aa79105071911273347b3f8@mail.gmail.com> References: <1120055659.3221.6.camel@remedyz.boston.redhat.com> <1120056858.9519.92.camel@blaa> <1120057787.3221.12.camel@remedyz.boston.redhat.com> <604aa79105071910375dbea9da@mail.gmail.com> <604aa79105071911273347b3f8@mail.gmail.com> Message-ID: <1121798548.3134.7.camel@remedyz.boston.redhat.com> Thanks Jef. I'm waiting on getting time to actually work on some issues I am seeing before I propose it again (like it dropping too many frames to be of much use). Of course if anyone is willing to be a more involved maintainer that I can be I also welcome that. I currently have a quarter of the desktop packages so things like this will often take a backburner for me. I do want to see it get in so at somepoint if no one else is interested I am going to dive into it again. On Tue, 2005-07-19 at 14:27 -0400, Jeff Spaleta wrote: > On 7/19/05, Jeff Spaleta wrote: > > It looks like you need to add a BuildRequires for gtk2-devel and > > python-devel to the spec. Once I add those 2 BuildRequires mock build > > goes through against the fedora development tree. > > Here is the srpm and binary package output from mock along with the > spec file which includes the modifications I made to get this to build > against the fedora development tree. > According to the requirements specified previously by j5 this won't > build against fc4 or earlier unless some dependancies are updated in > core. I can't comment if those are overstrict requirements or not. > > http://jef.is-a-geek.com/downloads/istanbul/ > > rpmlint output from the mock built binary: > E: istanbul description-line-too-long Istanbul is a desktop session > recorder. You can use it to record your desktop session and then play > it back for demos, tutorials and presentations. Sessions are recorded > to ogg theora files for later playback. > E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/README > E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/AUTHORS > E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/NEWS > W: istanbul empty-%post > W: istanbul empty-%postun > > Not sure if there needs to be a post or postun scriptlet. J5 would > probably have to comment. > I'm just providing these packages to fix the mock build problems. I > can't comment on anything that isnt a glaring build error. Im > assuming J5 i still interested in maintaining this as part of extras. > > -jef -- John (J5) Palmieri From chris at chrisgrau.com Tue Jul 19 19:08:44 2005 From: chris at chrisgrau.com (Chris Grau) Date: Tue, 19 Jul 2005 12:08:44 -0700 Subject: Request for review / approval: frotz. In-Reply-To: <20050719173055.35e92406.bugs.michael@gmx.net> References: <20050708172425.GA31553@chrisgrau.com> <20050719141101.GD31746@chrisgrau.com> <1121785113.32518.110.camel@localhost.localdomain> <20050719173055.35e92406.bugs.michael@gmx.net> Message-ID: <20050719190844.GE21103@chrisgrau.com> On Tue, Jul 19, 2005 at 05:30:55PM +0200, Michael Schwendt wrote: > On Tue, 19 Jul 2005 09:58:33 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2005-07-19 at 07:11 -0700, Chris Grau wrote: > > > > > Here are the updated files: > > > > > > http://www.chrisgrau.com/packages/frotz/frotz.spec > > > http://www.chrisgrau.com/packages/frotz/frotz-2.43-2.fc4.cdg.src.rpm > > > > Review: frotz > > > > Good: [snipped Tom's review] > > > > APPROVED. Very good first package. :) > > > > Now, what you need to do is go ahead and get an account here: > > https://admin.fedora.redhat.com/accounts/ > > > > When your paperwork is in, I'll sponsor you. > > > > ~spot > > Two hints here: > > : %build > : sed -e "s/@@OPTS@@/$RPM_OPT_FLAGS/" Makefile > Makefile.tmp > : mv Makefile.tmp Makefile > > sed -i (of at least FC2) can substitute in a file directly: > > sed -i -e "s/@@OPTS@@/$RPM_OPT_FLAGS/" Makefile I wasn't aware of that option, though as a heavy user of Perl one would think I'd have at least looked for it. > : make %{?_smp_mflags} > : gzip doc/frotz.6 > > Compressing manual pages manually is not necessary. rpmbuild does > this automatically. %{_mandir}/man6/frotz.6* in %files section then. I wasn't aware of that either. > These may need investigation: > > src/curses/ux_text.c: In function 'os_display_char': > src/curses/ux_text.c:209: warning: comparison is always true due to limited range of data type > src/curses/ux_text.c: In function 'os_char_width': > src/curses/ux_text.c:280: warning: comparison is always true due to limited range of data type I looked over the code in question. Looks like a red herring based on an implicit type cast, though I'm not entirely sure. I reported the warnings upstream to see what the author thinks of them. Thanks for the hints above. I've updated the spec file to reflect those changes. -chris From dwmw2 at infradead.org Tue Jul 19 19:30:51 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 Jul 2005 15:30:51 -0400 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050718141223.GA14908@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> Message-ID: <1121801452.21829.8.camel@localhost.localdomain> On Mon, 2005-07-18 at 09:12 -0500, Steven Pritchard wrote: > amavisd-new (which I'm working on right now) and spamassassin both > want this: > > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-1.src.rpm We should fix SpamAssassin not to use it by default -- SPF is a _very_ broken concept. http://david.woodhou.se/why-not-spf.html While you _can_ contrive non-harmful ways to use SPF, it really isn't a very good idea for us to be packaging it, shipping it, and generally making it easy for people to use it. It's major intended usage is fundamentally broken. -- dwmw2 From Nicolas.Mailhot at laPoste.net Tue Jul 19 19:38:03 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 19 Jul 2005 21:38:03 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121801452.21829.8.camel@localhost.localdomain> References: <20050718141223.GA14908@osiris.silug.org> <1121801452.21829.8.camel@localhost.localdomain> Message-ID: <1121801883.26376.4.camel@rousalka.dyndns.org> Le mardi 19 juillet 2005 ? 15:30 -0400, David Woodhouse a ?crit : > On Mon, 2005-07-18 at 09:12 -0500, Steven Pritchard wrote: > > amavisd-new (which I'm working on right now) and spamassassin both > > want this: > > > > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-1.src.rpm > > We should fix SpamAssassin not to use it by default -- SPF is a _very_ > broken concept. http://david.woodhou.se/why-not-spf.html > > While you _can_ contrive non-harmful ways to use SPF, it really isn't a > very good idea for us to be packaging it, shipping it, and generally > making it easy for people to use it. It's major intended usage is > fundamentally broken. On one hand you're right, on another I trust the spamassassin developers to give the SPF tests the weight they deserve, and not having added this dep if it didn't help a bit. Most of the sa tests are euristics anyway. sa works because their results are cross-referenced -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora-extras-list at cygnusx-1.org Tue Jul 19 19:58:10 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 19 Jul 2005 12:58:10 -0700 Subject: clamd handicraft work In-Reply-To: <873br0rxur.fsf@kosh.bigo.ensc.de> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> Message-ID: <1121803090.31954.3.camel@ws.1sttier.net> On Thu, 2005-06-30 at 11:35 +0200, Enrico Scholz wrote: > For what do you need a clamd-instance? The 'clamd' daemon is only useful > for special services (e.g. amavisd, mimedefang) and there can not exist > a single clamd instance which fits for all these services. Users do not > need the daemon overall; 'clamscan' works without it also. > > For full information, I suggest to read the corresponding tickets on > fedora.us's bugzilla. Most of the design decisions of the clamav package > are explained there. > > http://bugzilla.fedora.us/show_bug.cgi?id=268 > http://bugzilla.fedora.us/show_bug.cgi?id=1508 > http://bugzilla.fedora.us/show_bug.cgi?id=1715 I understand the reason why you did the clamav package the way you did, but overall your results are much worse than dag's or other's who package clamav. The convoluted setup your package requires isn't much better than just starting with a tarball. I agree with Warren's idea of creating clamav-(package) packages. The current Fedora Extras clamav package is bad enough, I call for having it removed until someone can do a proper package. From tibbs at math.uh.edu Tue Jul 19 20:09:22 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 19 Jul 2005 15:09:22 -0500 Subject: clamd handicraft work In-Reply-To: <1121803090.31954.3.camel@ws.1sttier.net> (Nathan Grennan's message of "Tue, 19 Jul 2005 12:58:10 -0700") References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> Message-ID: >>>>> "NG" == Nathan Grennan writes: NG> The current Fedora Extras clamav package is bad enough, I call NG> for having it removed until someone can do a proper package. I have to object. At first I had issues with the package but after taking the time to understand the security issues I have to say I prefer it the way it is. When I saw the request for a skeleton clamav instance package I provided one for clamav-exim, but nobody was interested in commenting. - J< From wtogami at redhat.com Tue Jul 19 20:15:36 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Jul 2005 10:15:36 -1000 Subject: clamd handicraft work In-Reply-To: <1121803090.31954.3.camel@ws.1sttier.net> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> Message-ID: <42DD5F68.6000002@redhat.com> Nathan Grennan wrote: > On Thu, 2005-06-30 at 11:35 +0200, Enrico Scholz wrote: > >>For what do you need a clamd-instance? The 'clamd' daemon is only useful >>for special services (e.g. amavisd, mimedefang) and there can not exist >>a single clamd instance which fits for all these services. Users do not >>need the daemon overall; 'clamscan' works without it also. >> >>For full information, I suggest to read the corresponding tickets on >>fedora.us's bugzilla. Most of the design decisions of the clamav package >>are explained there. >> >>http://bugzilla.fedora.us/show_bug.cgi?id=268 >>http://bugzilla.fedora.us/show_bug.cgi?id=1508 >>http://bugzilla.fedora.us/show_bug.cgi?id=1715 > > > I understand the reason why you did the clamav package the way you did, > but overall your results are much worse than dag's or other's who > package clamav. The convoluted setup your package requires isn't much > better than just starting with a tarball. I agree with Warren's idea of > creating clamav-(package) packages. "Much worse" than naive and insecure by default packages? > > The current Fedora Extras clamav package is bad enough, I call for > having it removed until someone can do a proper package. Why agree with the idea of clamav-(service instance) packages and at the same time throw out the entire idea? You are just being irrationally upset that it requires extra configuration to get services working? Make those service instance packages and add them to Extras. Warren Togami wtogami at redhat.com From alex at dalloz.de Tue Jul 19 20:34:57 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Tue, 19 Jul 2005 22:34:57 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <42D7B1C3.9060009@linux-kernel.at> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> Message-ID: <1121805297.6862.81.camel@serendipity.dogma.lan> Am Fr, den 15.07.2005 schrieb Oliver Falk um 14:53: > > Renewed src.rpm and spec: > > http://www.uni-x.org/pam_abl-0.2.2-2.src.rpm > > http://www.uni-x.org/pam_abl.spec > > Approved. I'll send out the note in a few minutes. > Oliver Hi! A few hours ago I did run ./cvs-import.sh \ ~/redhat/SRPMS/pam_abl-0.2.2-2.src.rpm to get the approved src.rpm into CVS. At least as this is my first package and first contact with the CVS system I like to request a further approval and ok for going further for starting the build request. The docu http://www.fedoraproject.org/wiki/Extras/BuildRequests says to run "make build" - obvious after first running "cvs co pam_abl" in the workdir to get a local copy of the CVS package and then running the make command inside the $WORKDIR/pam_abl/devel dir - followed by a "cvs commit"?. Don't I have to specify for which branch I want the package to be build? Will it be build automatically for each current Fedora releases (3 and 4 actually) and rawhide/development? I am a bit unsure and don't want to break things. Thanks. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 19 20:41:20 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 19 Jul 2005 22:41:20 +0200 Subject: clamd handicraft work In-Reply-To: <1121803090.31954.3.camel@ws.1sttier.net> (Nathan Grennan's message of "Tue, 19 Jul 2005 12:58:10 -0700") References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> Message-ID: <87fyuamsun.fsf@kosh.bigo.ensc.de> fedora-extras-list at cygnusx-1.org (Nathan Grennan) writes: > I agree with Warren's idea of creating clamav-(package) packages. The clamav-devel package contains an experimental 'clamd-gen' script which should help in creating such packages. But it's a little bit outdated and like most package-generators, the results need manual corrections. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From fedora-extras-list at cygnusx-1.org Tue Jul 19 20:44:51 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 19 Jul 2005 13:44:51 -0700 Subject: clamd handicraft work In-Reply-To: <42DD5F68.6000002@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> Message-ID: <1121805891.8052.11.camel@ws.1sttier.net> On Tue, 2005-07-19 at 10:15 -1000, Warren Togami wrote: > "Much worse" than naive and insecure by default packages? I only use such packages with amavisd-new. Hence why they work for me, and why I favor something like clamav-amavisd. > > > > The current Fedora Extras clamav package is bad enough, I call for > > having it removed until someone can do a proper package. > > Why agree with the idea of clamav-(service instance) packages and at the > same time throw out the entire idea? You are just being irrationally > upset that it requires extra configuration to get services working? > Make those service instance packages and add them to Extras. It isn't an irrational anger. It is that the package in it's current state is a poor excuse for a package. Packages in my view should ideally work without any configuration in most cases. One of the main reasons I like packages is that you can easily known what is part of a package and also easily uninstall it. Enrico's package break such ideas. Since you have to manually setup files the package can't be easily uninstalled with just a rpm -e. Where as with clamav-(package) packages, they could just work and could be uninstalled fairly cleanly. A big part of why I asked for it to be removed is that I think for most people packages from other repos do a better job, and hence the package from extras gets in the way. That is on top of the issues I brought up above. I am willing to work with someone on creating clamav-(package) packages if it is what it takes to get rid of the current clamav package. From wtogami at redhat.com Tue Jul 19 20:58:44 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Jul 2005 10:58:44 -1000 Subject: clamd handicraft work In-Reply-To: <1121805891.8052.11.camel@ws.1sttier.net> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> Message-ID: <42DD6984.9050002@redhat.com> Nathan Grennan wrote: > > I am willing to work with someone on creating clamav-(package) > packages if it is what it takes to get rid of the current clamav > package. > Are you totally missing the point? The clamav-(something) packages are only instances of service script files to provide a service for a specific user of clamd. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Tue Jul 19 21:17:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jul 2005 23:17:44 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121805297.6862.81.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> Message-ID: <20050719231744.2be2165f.bugs.michael@gmx.net> On Tue, 19 Jul 2005 22:34:57 +0200, Alexander Dalloz wrote: > A few hours ago I did run > > ./cvs-import.sh \ ~/redhat/SRPMS/pam_abl-0.2.2-2.src.rpm > > to get the approved src.rpm into CVS. At least as this is my first > package and first contact with the CVS system I like to request a > further approval and ok for going further for starting the build > request. The docu > > http://www.fedoraproject.org/wiki/Extras/BuildRequests > > says to run "make build" - obvious after first running "cvs co pam_abl" > in the workdir to get a local copy of the CVS package and then running > the make command inside the $WORKDIR/pam_abl/devel dir - followed by a > "cvs commit"?. Not followed by a cvs commit. There is nothing you need to commit explicitly for a build request. "make build" modifies and commits the changed "tobuild" file for you. > Don't I have to specify for which branch I want the > package to be build? No, default is to determine the branch based on the directory you're in. > Will it be build automatically for each current > Fedora releases (3 and 4 actually) and rawhide/development? No, for that you would need to run "make build" in every branch directory, i.e. pam_abl/FC-4, pam_abl/FC-3 and so on. > I am a bit unsure and don't want to break things. Thanks. Watch fedora-extras-commits list mails and scream loudly if you think something broke. From smooge at gmail.com Tue Jul 19 21:26:22 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 19 Jul 2005 15:26:22 -0600 Subject: clamd handicraft work In-Reply-To: <42DD6984.9050002@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> Message-ID: <80d7e409050719142659669fb3@mail.gmail.com> On 7/19/05, Warren Togami wrote: > Nathan Grennan wrote: > > > > I am willing to work with someone on creating clamav-(package) > > packages if it is what it takes to get rid of the current clamav > > package. > > > > Are you totally missing the point? The clamav-(something) packages are > only instances of service script files to provide a service for a > specific user of clamd. > I think the main problem I see with these clamav conversations is a lack of understanding between the packagers and the people using it. It might help if the design decisions need to be better communicated than telling someone to go to bugzilla.us to find out why things were done this way. Adding a %doc Fedora-Packaging-Design-Faq.txt would be useful. [It is useful to have this in the package because there are too many situations where you have to troubleshoot a security package and you dont have internet access for some reason.] Here are the questions that I have asked myself about clamav: Why did you not use the DAG model for packaging up clamav? [We did a thorough security review and realized that there were possible problems with the DAG packaging of clamav. These included... ] Why is clamav-data and clamav-update seperate from clamav when they get updated at the same time and are pretty much needed for every box using clamav? [We thought it was a fun and new way to package up things.] How does one write a clamav-amavis, clamav-exim, clamav-mimedefang, clamav-postfix, etc RPM? [Answer seems to be "Help the developer update scripts in clamav-devel to meet your needs." ] Why are these written as seperate script instances? [Answer seems to be "The best security design for running clamav is to seperate each use of clamav to a seperate user or UID. This helps from any possible compromises in clamav from affecting multiple services."] Why doesnt clamav run as root? [Answer seems to be "Running clamav as root is not a good idea. .. fill in the usual compromise as root problems.] -- Stephen J Smoogen. CSIRT/Linux System Administrator From qspencer at ieee.org Tue Jul 19 21:30:52 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 19 Jul 2005 16:30:52 -0500 Subject: Request for review: umfpack Message-ID: <42DD710C.1070003@ieee.org> umfpack is a library for solving linear equations involving sparse matrices. It is used by the newest development versions of octave (the 2.9.x tree which is in preparation for an upcoming 3.0 release), which I plan to eventually include in the Extras development tree. An SRPM can be found at: http://webpages.charter.net/qspencer/octave/umfpack-4.4-1.src.rpm Please take a look at this. It builds pretty quickly. regards, Quentin From fedora-extras-list at cygnusx-1.org Tue Jul 19 21:47:52 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 19 Jul 2005 14:47:52 -0700 Subject: clamd handicraft work In-Reply-To: <42DD6984.9050002@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> Message-ID: <1121809672.8052.38.camel@ws.1sttier.net> On Tue, 2005-07-19 at 10:58 -1000, Warren Togami wrote: > Are you totally missing the point? The clamav-(something) packages are > only instances of service script files to provide a service for a > specific user of clamd. My problem with the current packages is that it is incomplete and designed around the idea of requiring manual setup. Otherwise, though they aren't the way I would have done it, it is good enough. I see two ways to improve the clamav-server package once some clamav-(package) packages are recreated. One, remove all references to manually setting it services. With the idea that people migrating will look at the package in it's current state and may not realize there are other packages, then assume they have to manually set it up. Two, add additional text informing users of the other packages, but leave the manually setup files and information in. This is a compromise that is sort of best of both worlds. I am still not sure I like this method in that it encourages manual setup of a new service using clamav instead of creating a new package. On the other hand probably not everyone sees it the way I do and may want to take the path of least resistance. Instead of creating their own package or waiting for someone else to do it for them. From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 19 22:11:59 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 20 Jul 2005 00:11:59 +0200 Subject: clamd handicraft work In-Reply-To: <80d7e409050719142659669fb3@mail.gmail.com> (Stephen J. Smoogen's message of "Tue, 19 Jul 2005 15:26:22 -0600") References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <80d7e409050719142659669fb3@mail.gmail.com> Message-ID: <87br4ymonk.fsf@kosh.bigo.ensc.de> smooge at gmail.com ("Stephen J. Smoogen") writes: > I think the main problem I see with these clamav conversations is a > lack of understanding between the packagers and the people using it. > It might help if the design decisions need to be better communicated > than telling someone to go to bugzilla.us to find out why things were > done this way. Adding a %doc Fedora-Packaging-Design-Faq.txt would be > useful. Ok; I will work on it. > [It is useful to have this in the package because there are > too many situations where you have to troubleshoot a security package > and you dont have internet access for some reason.] > > Here are the questions that I have asked myself about clamav: > > Why did you not use the DAG model for packaging up clamav? Changelogs indicate that the Fedora Extras package was written before DAG's one ;) > Why is clamav-data and clamav-update seperate from clamav when they > get updated at the same time and are pretty much needed for every box > using clamav? > > [We thought it was a fun and new way to package up things.] Not really ;) Let us begin with -update: update functionality is required/wanted both for the enduser tools (in the 'clamav' package) and for the server instances (based upon 'clamav-server'). As 'clamav' and 'clamav-server' do not dependent each other, the update functionality could be either packaged redundantly in both packages, or in a third one. I preferred the latter way. Additionally, 'clamav-update' introduces a dependency on cron which is not required by the other packages. 'clamav-data' contains only the plain database and the same arguments as above apply there. 'clamav-update' and '-data' are not in a common package as they are somehow contradictory: '-update' overrides dynamically all static files from '-data'. Plus, shipping the virus-db in a separate package allows update strategies where the database will be packaged separately and updated with the usual 'yum upgrade' mechanism. '-lib' is in an own package as there are projects requiring only the libraries but not the tools (which introduce addition dependencies). Reasons for '-devel' and '-milter' subpackages should be clear. > How does one write a clamav-amavis, clamav-exim, clamav-mimedefang, > clamav-postfix, etc RPM? There is a 'clamd-gen' script in the -devel package. But it's not perfect and has flaws. :( > Why are these written as seperate script instances? > > [Answer seems to be "The best security design for running clamav is to > seperate each use of clamav to a seperate user or UID. This helps from > any possible compromises in clamav from affecting multiple services."] Exactly. Using separate script instances requires less manual work than providing a common -server package which must be modified manually. E.g. usernames and socket pathnames can be preconfigured, and a 'clamd' instance for a second independent services (e.g. mail vs. squid checker) can be created easily. > Why doesnt clamav run as root? > > [Answer seems to be "Running clamav as root is not a good idea. .. > fill in the usual compromise as root problems.] Yes. Another, minor issue is, that it might not work as expected. E.g. on NFS based /home dirs, 'root' might be squashed to 'nfsnobody' having nearly no rights in the user homes. And, 'clamd' knows a 'SHUTDOWN' command and it is IMO a bad idea when users can shutdown system services. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From alex at dalloz.de Tue Jul 19 22:16:43 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 20 Jul 2005 00:16:43 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050719231744.2be2165f.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> Message-ID: <1121811403.6862.122.camel@serendipity.dogma.lan> Am Di, den 19.07.2005 schrieb Michael Schwendt um 23:17: Thank you Michael for helping me. > > http://www.fedoraproject.org/wiki/Extras/BuildRequests > > > > says to run "make build" - obvious after first running "cvs co pam_abl" > > in the workdir to get a local copy of the CVS package and then running > > the make command inside the $WORKDIR/pam_abl/devel dir - followed by a > > "cvs commit"?. > > Not followed by a cvs commit. There is nothing you need to commit > explicitly for a build request. "make build" modifies and commits the > changed "tobuild" file for you. Ok, seems that make is automatically changing the "tobuild" file based on Makefile.common. > > Don't I have to specify for which branch I want the > > package to be build? > > No, default is to determine the branch based on the directory > you're in. > > > Will it be build automatically for each current > > Fedora releases (3 and 4 actually) and rawhide/development? > > No, for that you would need to run "make build" in every branch directory, > i.e. pam_abl/FC-4, pam_abl/FC-3 and so on. For getting an approval based on what a packager committed to CVS running "cvs-import.sh is enough, right? But that has to be followed by running "cvs-import.sh -b for all current branches that is now my understanding. > > I am a bit unsure and don't want to break things. Thanks. > > Watch fedora-extras-commits list mails and scream loudly if you think > something broke. I am subscribed to that list, as demanded by the documentation, and watching out for messages helping me to find out what is expected by me to run. To sum up: - I now wait for approval from a review of pam_abl in devel branch of CVS - then running cvs-import.sh for FC3 and FC4 too - in devel, FC4 and FC3 branch directories in my local package directory in the workdir I will then run "make tag" and "make build" to initiate the build on the buildsystem Hope these questions do not sound too dumb, but all the steps aren't that obvious for me from following the documentation in wiki for feeling sure. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From bugs.michael at gmx.net Tue Jul 19 23:52:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 20 Jul 2005 01:52:33 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121811403.6862.122.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> <1121811403.6862.122.camel@serendipity.dogma.lan> Message-ID: <20050720015233.1fb439e8.bugs.michael@gmx.net> On Wed, 20 Jul 2005 00:16:43 +0200, Alexander Dalloz wrote: > - then running cvs-import.sh for FC3 and FC4 too How to import new packages on older branches? http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-ffbc4a432ba7fbda0cf1c4d9cf1697189ddd29dd http://fedoraproject.org/wiki/Extras/UsingCvsFaq > - in devel, FC4 and FC3 branch directories in my local package directory > in the workdir I will then run "make tag" and "make build" to initiate > the build on the buildsystem Yes, "make tag" because you use %{?dist} and because cvs-import.sh does not seem to substitute %{?dist} appropriately. Otherwise, cvs-import.sh tags the imported files for you automatically, failing for tags which exist already somewhere else. > Hope these questions do not sound too dumb, but all the steps aren't > that obvious for me from following the documentation in wiki for feeling > sure. Where the current documentation is poor, we should improve it. From fedora-extras-list at cygnusx-1.org Wed Jul 20 00:25:49 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 19 Jul 2005 17:25:49 -0700 Subject: clamd handicraft work In-Reply-To: <42DD6984.9050002@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> Message-ID: <1121819149.8052.41.camel@ws.1sttier.net> On Tue, 2005-07-19 at 10:58 -1000, Warren Togami wrote: > Are you totally missing the point? The clamav-(something) packages are > only instances of service script files to provide a service for a > specific user of clamd. I have made my own clamav-amavis package. In the process I found the wrapper setup a little bit more complex than it needed to be, but got it working. Below is a link to my source rpm. Please review it. http://ws.1sttier.net/~edgan/clamav-amavis/clamav-amavis-0.1-1.src.rpm From wtogami at redhat.com Wed Jul 20 00:41:37 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Jul 2005 14:41:37 -1000 Subject: clamd handicraft work In-Reply-To: <1121819149.8052.41.camel@ws.1sttier.net> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> Message-ID: <42DD9DC1.1020503@redhat.com> Nathan Grennan wrote: > On Tue, 2005-07-19 at 10:58 -1000, Warren Togami wrote: > >>Are you totally missing the point? The clamav-(something) packages are >>only instances of service script files to provide a service for a >>specific user of clamd. > > > I have made my own clamav-amavis package. In the process I found the > wrapper setup a little bit more complex than it needed to be, but got it > working. Below is a link to my source rpm. Please review it. > > http://ws.1sttier.net/~edgan/clamav-amavis/clamav-amavis-0.1-1.src.rpm > This is not a complete review, and I'm guessing most of these problems are the result of the gen script, so these should be corrected there first. clamav-amavis-0.1.tar.bz2 contains: -rw-r--r-- 1 builder3 builder3 8137 Jul 19 13:23 clamd.amavis.conf -rwxr-xr-x 1 builder3 builder3 148 Jul 19 13:32 clamd.amavis.init -rw-r--r-- 1 builder3 builder3 130 Jul 19 13:24 clamd.amavis.logrotate -rw-r--r-- 1 builder3 builder3 104 Jul 19 13:25 clamd.amavis.sysconfig Rather than tar this up, we should add them as SOURCE0, SOURCE1, etc and check into CVS, so changes to the scripts can be tracked. It is wasteful to use a tarball here because changes cannot be easily tracked. Summary: Configuration files for running clamd with %{service}d-new This macro use is just plain silly. Epoch: 0 nuke this. Warren Togami wtogami at redhat.com From fedora-extras-list at cygnusx-1.org Wed Jul 20 00:57:43 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 19 Jul 2005 17:57:43 -0700 Subject: clamd handicraft work In-Reply-To: <42DD9DC1.1020503@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <42DD9DC1.1020503@redhat.com> Message-ID: <1121821063.8052.44.camel@ws.1sttier.net> On Tue, 2005-07-19 at 14:41 -1000, Warren Togami wrote: > Rather than tar this up, we should add them as SOURCE0, SOURCE1, etc and > check into CVS, so changes to the scripts can be tracked. It is > wasteful to use a tarball here because changes cannot be easily tracked. Makes sense > Summary: Configuration files for running clamd with %{service}d-new > This macro use is just plain silly. Search and replace gone wrong. > Epoch: 0 > nuke this. ok From fedora-extras-list at cygnusx-1.org Wed Jul 20 01:04:30 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 19 Jul 2005 18:04:30 -0700 Subject: clamd handicraft work In-Reply-To: <42DD9DC1.1020503@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <42DD9DC1.1020503@redhat.com> Message-ID: <1121821470.8052.46.camel@ws.1sttier.net> On Tue, 2005-07-19 at 14:41 -1000, Warren Togami wrote: > This is not a complete review, and I'm guessing most of these problems > are the result of the gen script, so these should be corrected there first. Here is my new release. http://ws.1sttier.net/~edgan/clamav-amavis/clamav-amavis-0.1-2.src.rpm From mricon at gmail.com Wed Jul 20 02:49:57 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 19 Jul 2005 22:49:57 -0400 Subject: libxml++ is old Message-ID: Hi, all: libxml++ in the tree is pretty ancient. In fact, it was last touched in 2003 and was migrated from fedora.us. Any way we can move on to libxml++-2.6? Does anything depend on the old API? Cheers, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From wtogami at redhat.com Wed Jul 20 03:46:33 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 19 Jul 2005 17:46:33 -1000 Subject: libxml++ is old In-Reply-To: References: Message-ID: <42DDC919.9010503@redhat.com> Konstantin Ryabitsev wrote: > Hi, all: > > libxml++ in the tree is pretty ancient. In fact, it was last touched > in 2003 and was migrated from fedora.us. Any way we can move on to > libxml++-2.6? Does anything depend on the old API? > > Cheers, You do realize that we have libxml2? % rpm -q libxml2 libxml2-2.6.19-1 From ivazquez at ivazquez.net Wed Jul 20 04:04:29 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 20 Jul 2005 00:04:29 -0400 Subject: libxml++ is old In-Reply-To: <42DDC919.9010503@redhat.com> References: <42DDC919.9010503@redhat.com> Message-ID: <1121832269.28256.40.camel@ignacio.lan> On Tue, 2005-07-19 at 17:46 -1000, Warren Togami wrote: > Konstantin Ryabitsev wrote: > > Hi, all: > > > > libxml++ in the tree is pretty ancient. In fact, it was last touched > > in 2003 and was migrated from fedora.us. Any way we can move on to > > libxml++-2.6? Does anything depend on the old API? > > > > Cheers, > > You do realize that we have libxml2? > > % rpm -q libxml2 > libxml2-2.6.19-1 libxml++ is C++ bindings for libxml/libxml2. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mricon at gmail.com Wed Jul 20 04:04:38 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Wed, 20 Jul 2005 00:04:38 -0400 Subject: libxml++ is old In-Reply-To: <42DDC919.9010503@redhat.com> References: <42DDC919.9010503@redhat.com> Message-ID: On 19/07/05, Warren Togami wrote: > Konstantin Ryabitsev wrote: > > Hi, all: > > > > libxml++ in the tree is pretty ancient. In fact, it was last touched > > in 2003 and was migrated from fedora.us. Any way we can move on to > > libxml++-2.6? Does anything depend on the old API? > > You do realize that we have libxml2? > > % rpm -q libxml2 > libxml2-2.6.19-1 You do realize they aren't the same thing, right? :) -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From veillard at redhat.com Wed Jul 20 04:10:08 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 20 Jul 2005 00:10:08 -0400 Subject: libxml++ is old In-Reply-To: <1121832269.28256.40.camel@ignacio.lan> References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> Message-ID: <20050720041007.GA2932@redhat.com> On Wed, Jul 20, 2005 at 12:04:29AM -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-07-19 at 17:46 -1000, Warren Togami wrote: > > Konstantin Ryabitsev wrote: > > > Hi, all: > > > > > > libxml++ in the tree is pretty ancient. In fact, it was last touched > > > in 2003 and was migrated from fedora.us. Any way we can move on to > > > libxml++-2.6? Does anything depend on the old API? > > > > > > Cheers, > > > > You do realize that we have libxml2? > > > > % rpm -q libxml2 > > libxml2-2.6.19-1 > > libxml++ is C++ bindings for libxml/libxml2. Right, well more precisely it is *one* of the C++ bindings for libxml2 though those days it clearly the most popular. The question still remains: what uses it ? If there was really a shortage for maintainers and a need I could try to handle it myself, but I would rather delegate :-) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From steve at silug.org Wed Jul 20 13:39:52 2005 From: steve at silug.org (Steven Pritchard) Date: Wed, 20 Jul 2005 08:39:52 -0500 Subject: clamd handicraft work In-Reply-To: <1121819149.8052.41.camel@ws.1sttier.net> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> Message-ID: <20050720133952.GA28474@osiris.silug.org> On Tue, Jul 19, 2005 at 05:25:49PM -0700, Nathan Grennan wrote: > I have made my own clamav-amavis package. In the process I found the > wrapper setup a little bit more complex than it needed to be, but got it > working. Below is a link to my source rpm. Please review it. I don't really think that's a good idea. The amavisd-new package I'm working on includes all the clamav integration. 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 derrick_moser at yahoo.com Wed Jul 20 13:42:50 2005 From: derrick_moser at yahoo.com (Derrick Moser) Date: Wed, 20 Jul 2005 14:42:50 +0100 (BST) Subject: Sponsor request and ownership claim: iiimf-le-simplehangul In-Reply-To: <42DC9601.8000300@redhat.com> Message-ID: <20050720134251.51527.qmail@web54102.mail.yahoo.com> --- Warren Togami wrote: > Does your new upstream version work with both FC3 > and FC4, or it is a > fork that works only with FC4's IIIMF directory > layout and API? Just > curious. The new version at http://sf.net/projects/simplehangul/ has only been tried on FC4. SimpleHangul does not use any of the APIs that changed in FC4 but it was affected by the change to the directory layout. > http://fedoraproject.org/wiki/Extras > Please be sure to read and follow the guidelines > here when making > changes to your package, and respect package > ownership (don't touch > packages not owned by you). If you are unsure about > proper packaging > procedure, you may request a review from the list by > providing a URL to > a .src.rpm or pointing at the CVS. Will do. Cheers, Derrick Send instant messages to your online friends http://uk.messenger.yahoo.com From mricon at gmail.com Wed Jul 20 14:03:06 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Wed, 20 Jul 2005 10:03:06 -0400 Subject: libxml++ is old In-Reply-To: <20050720041007.GA2932@redhat.com> References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> <20050720041007.GA2932@redhat.com> Message-ID: On 20/07/05, Daniel Veillard wrote: > > libxml++ is C++ bindings for libxml/libxml2. > > Right, well more precisely it is *one* of the C++ bindings for libxml2 > though those days it clearly the most popular. The question still remains: > what uses it ? If there was really a shortage for maintainers and a need > I could try to handle it myself, but I would rather delegate :-) How hard would it be to create, analogously to libxml/libxml2, libxml++ and libxml2++? Does libxml++-2.x live happily alongside libxml++-1.x? Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From veillard at redhat.com Wed Jul 20 14:45:49 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 20 Jul 2005 10:45:49 -0400 Subject: libxml++ is old In-Reply-To: References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> <20050720041007.GA2932@redhat.com> Message-ID: <20050720144548.GA29875@redhat.com> On Wed, Jul 20, 2005 at 10:03:06AM -0400, Konstantin Ryabitsev wrote: > On 20/07/05, Daniel Veillard wrote: > > > libxml++ is C++ bindings for libxml/libxml2. > > > > Right, well more precisely it is *one* of the C++ bindings for libxml2 > > though those days it clearly the most popular. The question still remains: > > what uses it ? If there was really a shortage for maintainers and a need > > I could try to handle it myself, but I would rather delegate :-) > > How hard would it be to create, analogously to libxml/libxml2, > libxml++ and libxml2++? Does libxml++-2.x live happily alongside > libxml++-1.x? libxml v1 is dead. the libxml++ jump in numbering isn't as drastic a jump as it was for libxml. And I would rather avoid keeping dual versions for the C++ bindings if there is nothing really requiring the old one. So back to the core question: what is using libxml C++ bindings ? Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From orion at cora.nwra.com Wed Jul 20 14:54:38 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 08:54:38 -0600 Subject: Request for review: umfpack In-Reply-To: <42DD710C.1070003@ieee.org> References: <42DD710C.1070003@ieee.org> Message-ID: <42DE65AE.1030808@cora.nwra.com> Quentin Spencer wrote: > umfpack is a library for solving linear equations involving sparse > matrices. It is used by the newest development versions of octave (the > 2.9.x tree which is in preparation for an upcoming 3.0 release), which I > plan to eventually include in the Extras development tree. An SRPM can > be found at: > > http://webpages.charter.net/qspencer/octave/umfpack-4.4-1.src.rpm > > Please take a look at this. It builds pretty quickly. > # rpmlint umfpack umfpack-devel W: umfpack invalid-license Freely distributable W: umfpack-devel invalid-license Freely distributable Not sure if this is rpmlint issue or not, I'm not that up on my licenses. License text is included and looks good. Is the AMD library of any use broken out? Are we going to conflict with anything else using libamd? Probably want to remove commented stuff in %prep: %prep %setup -q -n UMFPACKv%{version} %patch0 -p0 #%setup -q -c %{name}-%{version} #mv UMFPACKv%{version} shared #cp -a shared static I would be explicit and own the include directory: %{_includedir}/umfpack/ -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From fedora-extras-list at cygnusx-1.org Wed Jul 20 14:54:43 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Wed, 20 Jul 2005 07:54:43 -0700 Subject: clamd handicraft work In-Reply-To: <20050720133952.GA28474@osiris.silug.org> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> Message-ID: <1121871283.26403.5.camel@proton.cygnusx-1.org> On Wed, 2005-07-20 at 08:39 -0500, Steven Pritchard wrote: > I don't really think that's a good idea. The amavisd-new package I'm > working on includes all the clamav integration. By making it a separate package you allow the user choice. Not all people will want to use clamav, and so adding it to the amavisd-new package seems like a bad idea. Personally I use clamav and uvscan. I did set clamav-amavis to require amavisd-new. From ville.skytta at iki.fi Wed Jul 20 15:14:50 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 20 Jul 2005 18:14:50 +0300 Subject: Request for review: umfpack In-Reply-To: <42DE65AE.1030808@cora.nwra.com> References: <42DD710C.1070003@ieee.org> <42DE65AE.1030808@cora.nwra.com> Message-ID: <1121872490.14525.192.camel@localhost.localdomain> On Wed, 2005-07-20 at 08:54 -0600, Orion Poplawski wrote: > # rpmlint umfpack umfpack-devel > W: umfpack invalid-license Freely distributable > W: umfpack-devel invalid-license Freely distributable > > Not sure if this is rpmlint issue or not, I'm not that up on my > licenses. License text is included and looks good. Such licenses are often called just "Distributable" in a lot of FC/FE packages, and rpmlint is happy with that. See /etc/rpmlint/config. From qspencer at ieee.org Wed Jul 20 15:49:42 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 20 Jul 2005 10:49:42 -0500 Subject: Request for review: umfpack In-Reply-To: <42DE65AE.1030808@cora.nwra.com> References: <42DD710C.1070003@ieee.org> <42DE65AE.1030808@cora.nwra.com> Message-ID: <42DE7296.3090305@ieee.org> Orion Poplawski wrote: > Quentin Spencer wrote: > >> umfpack is a library for solving linear equations involving sparse >> matrices. It is used by the newest development versions of octave >> (the 2.9.x tree which is in preparation for an upcoming 3.0 release), >> which I plan to eventually include in the Extras development tree. An >> SRPM can be found at: >> >> http://webpages.charter.net/qspencer/octave/umfpack-4.4-1.src.rpm >> >> Please take a look at this. It builds pretty quickly. >> > > # rpmlint umfpack umfpack-devel > W: umfpack invalid-license Freely distributable > W: umfpack-devel invalid-license Freely distributable > > Not sure if this is rpmlint issue or not, I'm not that up on my > licenses. License text is included and looks good. I'll take Ville's suggestion and put just "Distributable". I got "freely distributable" from the spec file for lapack, which has a similar license. > Is the AMD library of any use broken out? Are we going to conflict > with anything else using libamd? I doubt it. It's also very specific to sparse matrices, and I think it would be unlikely to be used by anything other than octave or maybe eventually some other high-level language like Python. I borrowed heavily from the Debian package in writing the spec file. If anyone would have found a possible conflict by now, I figure Debian would have. > Probably want to remove commented stuff in %prep: > > %prep > %setup -q -n UMFPACKv%{version} > %patch0 -p0 > #%setup -q -c %{name}-%{version} > #mv UMFPACKv%{version} shared > #cp -a shared static > > > I would be explicit and own the include directory: > > %{_includedir}/umfpack/ I'll fix this. I'm not familiar with the details of how the %files section works. Do you mean putting this on a separate line from the line where the contents of the directory are included? -Quentin From jspaleta at gmail.com Wed Jul 20 15:51:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jul 2005 11:51:40 -0400 Subject: libxml++ is old In-Reply-To: <20050720144548.GA29875@redhat.com> References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> <20050720041007.GA2932@redhat.com> <20050720144548.GA29875@redhat.com> Message-ID: <604aa791050720085122d5e64c@mail.gmail.com> On 7/20/05, Daniel Veillard wrote: > So > back to the core question: what is using libxml C++ bindings ? proof that I can still learn new tricks. On my development box with fedora-core-development fedora-extras-development and livna-fc4 enabled repoquery --whatrequires --alldeps libxml++ returns only libxml++-devel on my fc4 box with fedora-core+updates fedora-extras and livna repoquery --whatrequires --alldeps libxml++ returns only libxml++-devel It looks like there isnt anything in Extras nor livna that is requiring this package. -jef From Jochen at herr-schmitt.de Wed Jul 20 16:21:35 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 20 Jul 2005 18:21:35 +0200 Subject: New Version: inadyn-1.95 Message-ID: <20050720162135.GA8507@myhome> Hello, I have create a new package for inadyn, becouse the version 1.95 was released. It will be nice, if anyone can make a look on it. A other question: What is the status of the build system. AFAIK it may be neccesary to install additional packages to initiate a build. The page on http://www.fedoraproject.com was unfinished about this topic. Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Wed Jul 20 16:31:35 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 10:31:35 -0600 Subject: APPROVED: umfpack In-Reply-To: <42DE7296.3090305@ieee.org> References: <42DD710C.1070003@ieee.org> <42DE65AE.1030808@cora.nwra.com> <42DE7296.3090305@ieee.org> Message-ID: <42DE7C67.8020508@cora.nwra.com> Quentin Spencer wrote: > Orion Poplawski wrote: >> I would be explicit and own the include directory: >> >> %{_includedir}/umfpack/ > > > I'll fix this. I'm not familiar with the details of how the %files > section works. Do you mean putting this on a separate line from the line > where the contents of the directory are included? > > -Quentin Sorry, replace your current includedir with the above line. That way you own the directory and everything underneath it. Otherwise looks good to me. I'll approve. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Wed Jul 20 16:35:05 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 10:35:05 -0600 Subject: Re-Request for review: kompose In-Reply-To: <42CB06AD.4040705@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> Message-ID: <42DE7D39.4070000@cora.nwra.com> Orion Poplawski wrote: > This is my first attempt at packaging a kde app, so there are surely > some issues. In particular, I don?t seem to get an icon in my KDE menu, > so I must not be installing icons is the right place or the .desktop > file must not be right. > > Description: > > Kompos? offers a great new way to manage a big number of windows on > different Virtual Desktops. It creates a fullscreen view where every > window is represented by a scaled screenshot of its own. > Thanks to the KDE framework it is possible to create those screenshots > "on the fly" while you are working without much overhead. The image > scaling is done through the high performance image library Imlib2. > > Since version 0.5 support for the Composite and Damage extensions has > been added, which allows us to display window contents without grabbing > screenshots. However with the current state of graphics drivers XOrg may > be awfully slow (or even crash sometimes) when enabling the Composite > extension. > So blame me for your bad gfx drivers :) > > URL http://kompose.berlios.de/ > > Package: > http://www.cora.nwra.com/~orion/fedora/kompose.spec > http://www.cora.nwra.com/~orion/fedora/kompose-0.5.2-0.beta1.src.rpm > Never got any takers, can someone please review? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Wed Jul 20 16:36:26 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 10:36:26 -0600 Subject: Re-Request for review: pytz and python-dateutil Message-ID: <42DE7D8A.30100@cora.nwra.com> Never got a review last time, trying again: I'm attempting to shift my python-matplotlib package to use upstream versions of pytz and dateutil. It bundles a version of each with it, but will not install if already present. So, it seems best to provide official versions of pytz and python-dateutil and have python-matplotlib require these to be present at build. So: pytz - World Timezone Definitions for Python Author: Stuart Bishop Introduction pytz brings the Olson tz database into Python. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. It also solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). Amost all (over 540) of the Olson timezones are supported [*]. http://pytz.sourceforge.net/ Package at: http://www.cora.nwra.com/~orion/fedora/pytz.spec http://www.cora.nwra.com/~orion/fedora/pytz-2005i-1.src.rpm python-dateutil: Description: The dateutil module provides powerful extensions to the standard datetime module, available in Python 2.3+. https://moin.conectiva.com.br/DateUtil Package at: http://www.cora.nwra.com/~orion/fedora/python-dateutil.spec http://www.cora.nwra.com/~orion/fedora/python-dateutil-0.9-1.src.rpm -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From bugs.michael at gmx.net Wed Jul 20 16:44:24 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 20 Jul 2005 18:44:24 +0200 Subject: Request for review: umfpack In-Reply-To: <42DE7296.3090305@ieee.org> References: <42DD710C.1070003@ieee.org> <42DE65AE.1030808@cora.nwra.com> <42DE7296.3090305@ieee.org> Message-ID: <20050720184424.5a02ef49.bugs.michael@gmx.net> On Wed, 20 Jul 2005 10:49:42 -0500, Quentin Spencer wrote: > > I would be explicit and own the include directory: > > > > %{_includedir}/umfpack/ > > I'll fix this. I'm not familiar with the details of how the %files > section works. Do you mean putting this on a separate line from the line > where the contents of the directory are included? Assume /foo/bar is a directory, then an entry like /foo/bar in the %files section includes the directory "bar" and its contents recursively. When listing the binary package contents, e.g. with rpm -qplv, you would see drwxr-xr-x ... /foo/bar -rw-r--r-- ... /foo/bar/file1.h -rw-r--r-- ... /foo/bar/file2.h -rw-r--r-- ... /foo/bar/file3.h drwxr-xr-x ... /foo/bar/subdir -rw-r--r-- ... /foo/bar/subdir/example.h Note the 'd' lines. On the contrary, if you just do /foo/bar/* in the %files section, you get only the files within the directory, but not the directory itself: -rw-r--r-- ... /foo/bar/file1.h -rw-r--r-- ... /foo/bar/file2.h -rw-r--r-- ... /foo/bar/file3.h drwxr-xr-x ... /foo/bar/subdir -rw-r--r-- ... /foo/bar/subdir/example.h Here /foo/bar is missing. Where you don't want to include entire directory trees recursively and when you list files explicitly (i.e. without wildcards), you can include directories separately: %dir /foo/bar /foo/bar/file1.h /foo/bar/file2.h %dir /foo/bar/subdir /foo/bar/subdir/example.h From orion at cora.nwra.com Wed Jul 20 16:41:57 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 10:41:57 -0600 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> Message-ID: <42DE7ED5.3040603@cora.nwra.com> Andreas Thienemann wrote: > On Fri, 15 Jul 2005, Orion Poplawski wrote: > > > %if "%fedora" >= "4" > BuildRequires: gcc-gfortran > %else > BuildRequires: gcc-g77 > %endif > > This should work. > > bye, > andreas > On my FC4 box I get: $ rpmbuild -ba *spec error: Failed build dependencies: gcc-g77 is needed by hdf-4.2r1-2.i386 So looks like %fedora is not defined on user machins, only in the build system? This won't work. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From alex at dalloz.de Wed Jul 20 16:46:18 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 20 Jul 2005 18:46:18 +0200 Subject: Request for review: keychain opt-in mechanism Message-ID: <1121877978.6862.174.camel@serendipity.dogma.lan> Hi all! Starting a new thread about keychain and especially the requested opt-in mechanism I like to request reviewing my fresh new script suggestion. The old thread is to be found as https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00593.html I am starting with a fresh new thread to focus on what the past discussion brought up to be helpful within the package. Ed Hill thankfully approved my presented keychain src.rpm on 13th - now as some of you (namely Chip Turner, Ed Hill, Ville Skytt?) voted for an ease of use mechanism I beg for criticising following: http://www.uni-x.org/README.Fedora That file shall inform Fedora users about the mechanism which isn't part of the upstream keychain tool/package. http://www.uni-x.org/keychain.sh http://www.uni-x.org/keychain.csh Those 2 scripts are to be placed in /etc/profile.d/. Please review and test them. It is needed to `touch ~/.keychainrc' or to fill that file with custom setting, to let the profile script doing their work. keychain is needed of course too; my formerly presented src.rpm is still available through http://www.uni-x.org/keychain-2.5.4.1-1.src.rpm Chip, you were so kind to have a close look at my last week's script - hope you have more joy with this attempt. Paul, you suggested to let /etc/profile.d/ call a wrapper script for the keychain ssh-agent wrapper. I tried to went that route but it was even more complicated to take care for all the possible shells a user can have. My suggestion now should work with bash, sh, csh, tcsh and zsh. With those I tested myself and didn't found a problem. So far I didn't test with ksh (KornShell) available through Core. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ivazquez at ivazquez.net Wed Jul 20 17:09:46 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 20 Jul 2005 13:09:46 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DE7ED5.3040603@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> Message-ID: <1121879387.28256.47.camel@ignacio.lan> On Wed, 2005-07-20 at 10:41 -0600, Orion Poplawski wrote: > Andreas Thienemann wrote: > > On Fri, 15 Jul 2005, Orion Poplawski wrote: > > > > > > %if "%fedora" >= "4" > > BuildRequires: gcc-gfortran > > %else > > BuildRequires: gcc-g77 > > %endif > > > > This should work. > > On my FC4 box I get: > > $ rpmbuild -ba *spec > error: Failed build dependencies: > gcc-g77 is needed by hdf-4.2r1-2.i386 > > So looks like %fedora is not defined on user machins, only in the build > system? This won't work. Put this in /etc/rpm: http://fedora.ivazquez.net/files/macros.disttag -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mricon at gmail.com Wed Jul 20 17:28:27 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Wed, 20 Jul 2005 13:28:27 -0400 Subject: libxml++ is old In-Reply-To: <20050720144548.GA29875@redhat.com> References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> <20050720041007.GA2932@redhat.com> <20050720144548.GA29875@redhat.com> Message-ID: On 20/07/05, Daniel Veillard wrote: > libxml v1 is dead. > the libxml++ jump in numbering isn't as drastic a jump as it was > for libxml. And I would rather avoid keeping dual versions for the > C++ bindings if there is nothing really requiring the old one. So > back to the core question: what is using libxml C++ bindings ? Looks like nothing requires it. I can add this to my collection of maintained packages, since I need to have it to package granule anyway. Unless there are other claimants, of course. Cheers, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From mattdm at mattdm.org Wed Jul 20 18:11:28 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jul 2005 14:11:28 -0400 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121801883.26376.4.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <1121801452.21829.8.camel@localhost.localdomain> <1121801883.26376.4.camel@rousalka.dyndns.org> Message-ID: <20050720181128.GA26434@jadzia.bu.edu> On Tue, Jul 19, 2005 at 09:38:03PM +0200, Nicolas Mailhot wrote: > On one hand you're right, on another I trust the spamassassin developers > to give the SPF tests the weight they deserve, and not having added this > dep if it didn't help a bit. And, if you're receiving forwarded e-mail, decrease the weighting. *shrug*. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From steve at silug.org Wed Jul 20 18:29:58 2005 From: steve at silug.org (Steven Pritchard) Date: Wed, 20 Jul 2005 13:29:58 -0500 Subject: clamd handicraft work In-Reply-To: <1121871283.26403.5.camel@proton.cygnusx-1.org> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <1121871283.26403.5.camel@proton.cygnusx-1.org> Message-ID: <20050720182958.GA575@osiris.silug.org> On Wed, Jul 20, 2005 at 07:54:43AM -0700, Nathan Grennan wrote: > On Wed, 2005-07-20 at 08:39 -0500, Steven Pritchard wrote: > > I don't really think that's a good idea. The amavisd-new package I'm > > working on includes all the clamav integration. > > By making it a separate package you allow the user choice. Not all > people will want to use clamav, and so adding it to the amavisd-new > package seems like a bad idea. Personally I use clamav and uvscan. I did > set clamav-amavis to require amavisd-new. I've thought about this before, and I can't think of a good reason for amavisd-new not to require clamav. If the daemon isn't running, amavisd-new will skip it, so nobody is forcing anyone to *use* clamav, just install it. Besides, even if someone uses another virus scanner, keeping clamav enabled makes a lot of sense... It will often pick up things the other virus scanners won't pick up (like a lot of the phishing scam mails). 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 orion at cora.nwra.com Wed Jul 20 19:28:28 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 20 Jul 2005 13:28:28 -0600 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <1121879387.28256.47.camel@ignacio.lan> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> <1121879387.28256.47.camel@ignacio.lan> Message-ID: <42DEA5DC.7020203@cora.nwra.com> Ignacio Vazquez-Abrams wrote: > On Wed, 2005-07-20 at 10:41 -0600, Orion Poplawski wrote: > >>Andreas Thienemann wrote: >> >>>On Fri, 15 Jul 2005, Orion Poplawski wrote: >>> >>> >>>%if "%fedora" >= "4" >>>BuildRequires: gcc-gfortran >>>%else >>>BuildRequires: gcc-g77 >>>%endif >>> >>>This should work. >> >>On my FC4 box I get: >> >>$ rpmbuild -ba *spec >>error: Failed build dependencies: >> gcc-g77 is needed by hdf-4.2r1-2.i386 >> >>So looks like %fedora is not defined on user machins, only in the build >>system? This won't work. > > > Put this in /etc/rpm: > > http://fedora.ivazquez.net/files/macros.disttag > Yeah, but that's not the point. The src.rpm should build fine out of the box on anyone's machine. Thanks though! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rdieter at math.unl.edu Wed Jul 20 20:36:03 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Jul 2005 15:36:03 -0500 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DEA5DC.7020203@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> <1121879387.28256.47.camel@ignacio.lan> <42DEA5DC.7020203@cora.nwra.com> Message-ID: Orion Poplawski wrote: > Ignacio Vazquez-Abrams wrote: > Yeah, but that's not the point. The src.rpm should build fine out of > the box on anyone's machine. IMO, the *point* here is to get things to build right on the Fedora Extras buildsystem. Now, If you want to get similar/identical results, you need to set those few extra rpm macros. -- Rex From jspaleta at gmail.com Wed Jul 20 21:20:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jul 2005 17:20:42 -0400 Subject: New Request for Review: istanbul - Now under new management Message-ID: <604aa791050720142012f60201@mail.gmail.com> With J5's blessing, I'm prepared to maintain the instabul package. For now its only going to be available for extras-development because of the gstreamer-plugins dependancy. If fc4 or fc3 gets the newer gstreamers-plugins at somepoint I'll gladly build for fc4 or fc3 as well. Starting with J5's initial packaging, I've cleaned up the spec a little bit more. I've gotten this to build and and used it to make some example screencasts. There are caveats about performance since the ximagesrc gst element which istanbul is relying on is still under active development and just showed up in the gstreamer--plugins now available in rawhide. I'm prepared to create a short wiki howto on the fedoraproject page with recommendations on how to use istanbul to avoid egregious problems with framedrops for the time being. I can add version of that howto into this package as a package update at some point in the future if the performance issues aren't addressed in the time from of the fc5 test releases. Url: http://live.gnome.org/Istanbul Description: Istanbul is a desktop session recorder. You can use it to record your desktop session and then play it back for demos, tutorials and presentations. Sessions are recorded to ogg theora files for later playback. You can find the mock built binary and srpm at http://jef.is-a-geek.com/downloads/istanbul/ An example screencast using a version of instanbul i built locally at: http://jef.is-a-geek.com/downloads/desktop-recording.ogg So please if you are interested in a native screencasting support in Fedora, take a moment and review the package for approval into extras-development. Notes: rpmlint istanbul-0.1.1-3.i386.rpm returns: E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/README E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/AUTHORS E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/NEWS all 3 files are zero-length in the source tarball? Keep them in the rpm or exclude them? W: istanbul empty-%post Should i remove the empty postun and post sections from the spec? I went over the scriptlet scenarios outlined in the wiki, none seem to apply. no translations provided yet so find_lang macro is not being used. -jef From andreas.bierfert at lowlatency.de Wed Jul 20 22:45:42 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 21 Jul 2005 00:45:42 +0200 Subject: Request for review: koffice In-Reply-To: <42C46C17.3050805@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> Message-ID: <42DED416.3010609@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok why is koffice being checked in to extras without any notice to this thread? - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC3tQVQEQyPsWM8csRAghGAJ4iZZZ0MLDaemkVBMRHcL5Q+QIw8QCdH9z0 GNKxKnXsO0VVPrcgFIjaqy0= =eSg4 -----END PGP SIGNATURE----- From dennis at ausil.us Wed Jul 20 22:51:05 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 20 Jul 2005 17:51:05 -0500 Subject: Request for review: koffice In-Reply-To: <42DED416.3010609@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <42DED416.3010609@lowlatency.de> Message-ID: <200507201751.05617.dennis@ausil.us> Once upon a time Wednesday 20 July 2005 5:45 pm, Andreas Bierfert wrote: > Ok why is koffice being checked in to extras without any notice to this > thread? > > - Andreas Seems like than is doing his own thing, He is not the person who was proposing koffice. I want koffice in extras. Regardless of who maintains it they need to follow the correct procedures. I think that thans import should be dropped and he should submit his SPEC file for approval like evryone else. Dennis From alex at dalloz.de Wed Jul 20 22:54:54 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Thu, 21 Jul 2005 00:54:54 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050720015233.1fb439e8.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> <1121811403.6862.122.camel@serendipity.dogma.lan> <20050720015233.1fb439e8.bugs.michael@gmx.net> Message-ID: <1121900094.6862.213.camel@serendipity.dogma.lan> Am Mi, den 20.07.2005 schrieb Michael Schwendt um 1:52: > On Wed, 20 Jul 2005 00:16:43 +0200, Alexander Dalloz wrote: > > > - then running cvs-import.sh for FC3 and FC4 too > > How to import new packages on older branches? > http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-ffbc4a432ba7fbda0cf1c4d9cf1697189ddd29dd > > http://fedoraproject.org/wiki/Extras/UsingCvsFaq I was following or even tried to follow those instructions. Unfortunately the CVSSyncNeeded page was either much too obvious, I am too brain dead or a mixture of both, so that I didn't see what to do exacty. With help from Elliot in IRC I now see that the wiki is not only the place of the documentation but too used for Fedora processes, such like the branch creation request log. While talking to Elliot he was so kind and created the FC3 and FC4 branches for pam_abl for me. As pam_abl was reviewed and approved by Oliver Falk last Friday based on the src.rpm, there seems to be no real reason why another review is required now based on CVS info. At least I did understand Elliot in this way. So if nobody protests I will soon request a build for devel, FC4 and FC3. > > - in devel, FC4 and FC3 branch directories in my local package directory > > in the workdir I will then run "make tag" and "make build" to initiate > > the build on the buildsystem > > Yes, "make tag" because you use %{?dist} and because cvs-import.sh > does not seem to substitute %{?dist} appropriately. Otherwise, > cvs-import.sh tags the imported files for you automatically, > failing for tags which exist already somewhere else. Ok, http://www.fedoraproject.org/wiki/Extras/BuildRequests is clear about this aspect. > > Hope these questions do not sound too dumb, but all the steps aren't > > that obvious for me from following the documentation in wiki for feeling > > sure. > > Where the current documentation is poor, we should improve it. When I get another package into CVS and I am feeling that most of my questions are not questionable any longer I will try to make some remarks about where I stumbled first time. Thank you Michael. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From wolfy at nobugconsulting.ro Wed Jul 20 23:35:49 2005 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Thu, 21 Jul 2005 02:35:49 +0300 Subject: clamd handicraft work In-Reply-To: <20050720182958.GA575@osiris.silug.org> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <1121871283.26403.5.camel@proton.cygnusx-1.org> <20050720182958.GA575@osiris.silug.org> Message-ID: <42DEDFD5.8080508@nobugconsulting.ro> Steven Pritchard wrote: > On Wed, Jul 20, 2005 at 07:54:43AM -0700, Nathan Grennan wrote: > >>On Wed, 2005-07-20 at 08:39 -0500, Steven Pritchard wrote: >> >>>I don't really think that's a good idea. The amavisd-new package I'm >>>working on includes all the clamav integration. >> >> By making it a separate package you allow the user choice. Not all >>people will want to use clamav, and so adding it to the amavisd-new >>package seems like a bad idea. Personally I use clamav and uvscan. I did >>set clamav-amavis to require amavisd-new. correct > > > I've thought about this before, and I can't think of a good reason for > amavisd-new not to require clamav. If the daemon isn't running, > amavisd-new will skip it, so nobody is forcing anyone to *use* clamav, > just install it. I am far from being an expert and I might be psychotic or paranoid, but I really really love to NOT be forced to install a package which I know for sure I will not use. That's one of the reasons I always recompile mc before installing it on servers (which never run X). The "current" (i.e. for several years..) version of mc.rpm always pulls in X libs. The issue is NOT that amavis will skip clamav if the daemon is not running. The issue is that you are forcing the user(s) to install a package, which might go un-noticed in case of security announces ("I am not using it, why should I care about it?") From symbiont at berlios.de Wed Jul 20 23:48:23 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 21 Jul 2005 07:48:23 +0800 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <42DEA5DC.7020203@cora.nwra.com> References: <42D82113.5030005@cora.nwra.com> <1121879387.28256.47.camel@ignacio.lan> <42DEA5DC.7020203@cora.nwra.com> Message-ID: <200507210748.23591.symbiont@berlios.de> On Thursday 21 July 2005 03:28, Orion Poplawski wrote: > Yeah, but that's not the point. ?The src.rpm should build fine out of > the box on anyone's machine. ?Thanks though! http://fedoraproject.org/buildgroups/4/i386/ FWIW, you can BuildRequires: buildsys-macros, if you really want. The above is yumable. enjoy, -- -jeff From gdk at redhat.com Thu Jul 21 00:23:46 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 20 Jul 2005 20:23:46 -0400 (EDT) Subject: Request for review: koffice In-Reply-To: <200507201751.05617.dennis@ausil.us> References: <42C46C17.3050805@lowlatency.de> <42DED416.3010609@lowlatency.de> <200507201751.05617.dennis@ausil.us> Message-ID: On Wed, 20 Jul 2005, Dennis Gilmore wrote: > Once upon a time Wednesday 20 July 2005 5:45 pm, Andreas Bierfert wrote: > > Ok why is koffice being checked in to extras without any notice to this > > thread? > > > Seems like than is doing his own thing, He is not the person who was > proposing koffice. I want koffice in extras. Regardless of who > maintains it they need to follow the correct procedures. I think that > thans import should be dropped and he should submit his SPEC file for > approval like evryone else. I completely agree. We're working on it. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From wtogami at redhat.com Thu Jul 21 00:42:49 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 14:42:49 -1000 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> <42DED416.3010609@lowlatency.de> <200507201751.05617.dennis@ausil.us> Message-ID: <42DEEF89.8080907@redhat.com> Greg DeKoenigsberg wrote: > On Wed, 20 Jul 2005, Dennis Gilmore wrote: > > >>Once upon a time Wednesday 20 July 2005 5:45 pm, Andreas Bierfert wrote: >> >>>Ok why is koffice being checked in to extras without any notice to this >>>thread? >>> >> >>Seems like than is doing his own thing, He is not the person who was >>proposing koffice. I want koffice in extras. Regardless of who >>maintains it they need to follow the correct procedures. I think that >>thans import should be dropped and he should submit his SPEC file for >>approval like evryone else. > > > I completely agree. We're working on it. Than has done absolutely nothing wrong. Red Hat engineers AFAIK have never bypassed any established process. We have however considered packages previously in Core but dropped as not requiring review before import into Extras. If this has not been noted in the procedures then THAT is my fault. Dennis if your package is superior to the original Red Hat package, then you are welcome to replace whatever is in CVS and become the new maintainer. I'll take a look at your package now myself. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Jul 21 00:46:24 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 14:46:24 -1000 Subject: Request for review: koffice In-Reply-To: <42DEEF89.8080907@redhat.com> References: <42C46C17.3050805@lowlatency.de> <42DED416.3010609@lowlatency.de> <200507201751.05617.dennis@ausil.us> <42DEEF89.8080907@redhat.com> Message-ID: <42DEF060.7090408@redhat.com> Warren Togami wrote: > > Than has done absolutely nothing wrong. Red Hat engineers AFAIK have > never bypassed any established process. We have however considered > packages previously in Core but dropped as not requiring review before > import into Extras. If this has not been noted in the procedures then > THAT is my fault. > > Dennis if your package is superior to the original Red Hat package, then > you are welcome to replace whatever is in CVS and become the new > maintainer. I'll take a look at your package now myself. > Another benefit of going from the RH package to your package in CVS is to conveniently see the difference between the two packages. There is nothing lost by having the old RH package imported then replaced by your package. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Jul 21 00:47:49 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 14:47:49 -1000 Subject: Request for review: koffice In-Reply-To: <42DEEF89.8080907@redhat.com> References: <42C46C17.3050805@lowlatency.de> <42DED416.3010609@lowlatency.de> <200507201751.05617.dennis@ausil.us> <42DEEF89.8080907@redhat.com> Message-ID: <42DEF0B5.1030206@redhat.com> Warren Togami wrote: > > Dennis if your package is superior to the original Red Hat package, then Oops, I meant Andreas Warren From wtogami at redhat.com Thu Jul 21 00:55:19 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 14:55:19 -1000 Subject: Request for review: koffice In-Reply-To: <42CD9CB0.80209@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> Message-ID: <42DEF277.1050507@redhat.com> Andreas Bierfert wrote: > > Thanks for your review. If you run into any other problems let me know. > > Anybody else willing to review? Or anybody against importing these packages to > cvs and if so why? ^^ BTW where is the latest version of your package? I have no idea where to download it. The Epoch related changes suggested by Rex earlier in the thread looked potentially wrong to me, so I want to see the latest version of the package in order to test it. (You also did not need review to import it in the first place, because it was previously in Core. It was my mistake that this was not noted in the procedures earlier. Both RH engineers and community contributors were following this exception during the past few months.) Warren Togami wtogami at redhat.com From fedora at tqmcube.com Thu Jul 21 01:12:25 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Wed, 20 Jul 2005 21:12:25 -0400 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121900094.6862.213.camel@serendipity.dogma.lan> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> <1121811403.6862.122.camel@serendipity.dogma.lan> <20050720015233.1fb439e8.bugs.michael@gmx.net> <1121900094.6862.213.camel@serendipity.dogma.lan> Message-ID: <1121908345.2172.91.camel@dch.TQMcube.com> On Thu, 2005-07-21 at 00:54 +0200, Alexander Dalloz wrote: > I was following or even tried to follow those instructions. > Unfortunately the CVSSyncNeeded page was either much too obvious, I am > too brain dead or a mixture of both, so that I didn't see what to do > exacty. With help from Elliot in IRC I now see that the wiki is not only > the place of the documentation but too used for Fedora processes, such > like the branch creation request log. > While talking to Elliot he was so kind and created the FC3 and FC4 > branches for pam_abl for me. > As pam_abl was reviewed and approved by Oliver Falk last Friday based on > the src.rpm, there seems to be no real reason why another review is > required now based on CVS info. At least I did understand Elliot in this > way. So if nobody protests I will soon request a build for devel, FC4 > and FC3. > Your post gives me hope that I am not such a mindless idiot. I am going to compare where I am at with leafnode with the documentation one more time tomorrow and then cry for help if it's still incomprehensible. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From wtogami at redhat.com Thu Jul 21 01:21:29 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 15:21:29 -1000 Subject: Wording of "Previously in Core" Procedure Message-ID: <42DEF899.1010205@redhat.com> I will be adding the exception that we had been following during the past few months to the NewPackageProcess. Maybe the wording will need to be cleaned up a bit, and I am not exactly sure where to add it to the current page. Please reply with suggestions and questions. "If the package has been in a previous Fedora Core stable release but it has been subsequently removed, then it requires no review to be imported into Fedora Extras. Existing Extras contributors may claim ownership by posting to fedora-extras-list with the package name in the Subject, importing the original RH package, then proceding to make improvements in CVS from that baseline." I explicitly state "Existing Extras contributors" here because adoption of an existing package written by someone else is most often never enough of an indicator to the sponsors if that new potential contributor truly understands packaging and has read the guidelines. One of the things decided upon at the FUDCON2 planning meeting was that new members can become sponsored only after one or more of their package submissions has been reviewed and approved. After this point a sponsor member can determine if it is the right thing to grant membership. Warren Togami wtogami at redhat.com From fedora-extras-list at cygnusx-1.org Thu Jul 21 01:36:34 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Wed, 20 Jul 2005 18:36:34 -0700 Subject: clamd handicraft work In-Reply-To: <20050720182958.GA575@osiris.silug.org> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <1121871283.26403.5.camel@proton.cygnusx-1.org> <20050720182958.GA575@osiris.silug.org> Message-ID: <1121909794.31249.4.camel@proton.cygnusx-1.org> On Wed, 2005-07-20 at 13:29 -0500, Steven Pritchard wrote: > I've thought about this before, and I can't think of a good reason for > amavisd-new not to require clamav. If the daemon isn't running, > amavisd-new will skip it, so nobody is forcing anyone to *use* clamav, > just install it. > > Besides, even if someone uses another virus scanner, keeping clamav > enabled makes a lot of sense... It will often pick up things the > other virus scanners won't pick up (like a lot of the phishing scam > mails). So you plan to include the files, but not enable it by default and make it a dependency? If you configure amavisd-new to look for the clamd socket file, it will leave errors in the logs about not being able to find it. Letting it detect the command line scanner by default is fine. If you do make it a dependency, which would be logical when including the files, then you have unnecessary dependency bloat. Also if other packages are going to use clamav, it would be nice to keep use of separate packages a standard way of doing things instead of some people including them in their own package and others creating a separate package. From wtogami at redhat.com Thu Jul 21 01:43:40 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 15:43:40 -1000 Subject: clamd handicraft work In-Reply-To: <1121909794.31249.4.camel@proton.cygnusx-1.org> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <1121871283.26403.5.camel@proton.cygnusx-1.org> <20050720182958.GA575@osiris.silug.org> <1121909794.31249.4.camel@proton.cygnusx-1.org> Message-ID: <42DEFDCC.30104@redhat.com> Nathan Grennan wrote: > > So you plan to include the files, but not enable it by default and > make it a dependency? If you configure amavisd-new to look for the clamd > socket file, it will leave errors in the logs about not being able to > find it. Letting it detect the command line scanner by default is fine. > If you do make it a dependency, which would be logical when including > the files, then you have unnecessary dependency bloat. I cannot say for certain because I personally have never used amavisd, but Nathan's reasoning above sounds good. In order to be sure about making the right decision together, it would be helpful if we had both an amavisd-new and clamav-amavis package to analyze in concert in order to make a better determination about optimal defaults and how the packages should be split. > Also if other > packages are going to use clamav, it would be nice to keep use of > separate packages a standard way of doing things instead of some people > including them in their own package and others creating a separate > package. This is a good argument, IMHO. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Thu Jul 21 02:44:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jul 2005 22:44:08 -0400 Subject: Run of repoclosure against core-development and extras-development Message-ID: <604aa791050720194435c82e37@mail.gmail.com> So on a whim., i ran repoclosure against development and extras-development. And of course I've got some out-of-sync packages in the extras tree due to the uptick in activity in rawhide. The question is what to do about broken deps i found? I'm loath to file individual bugreports manually everytime i get bored enough to do this run. Are we at the point where we can add an automated run of this periodicly that notifizes extras package maintainers about broken deps.. not unsimilar to the rawhide build report but perhaps not daily. Here is the output of repoclosure -r development -r extras-development on my x86 box cleansed to show only relevant items in Extras with broken deps: package: showimg - 0.9.4.1-2.i386 from extras-development unresolved deps: libexif.so.9 package: p0f - 2.0.5-3.i386 from extras-development unresolved deps: libpcap.so.0.8.3 package: brightside - 1.4.0-7.i386 from extras-development unresolved deps: libwnck-1.so.16 package: gcombust - 1:0.1.55-6.i386 from extras-development unresolved deps: cdlabelgen >= 0:1.5.0 package: hping2 - 2.0.0-0.4.rc3.i386 from extras-development unresolved deps: libpcap.so.0.8.3 package: gda-postgres - 1:1.2.0-5.i386 from extras-development unresolved deps: libpq.so.3 package: lft - 2.31-2.i386 from extras-development unresolved deps: libpcap.so.0.8.3 package: iftop - 0.16-4.i386 from extras-development unresolved deps: libpcap.so.0.8.3 package: apt-groupinstall - 0.5.15cnc7-2.i386 from extras-development unresolved deps: comps package: screem - 0.14.1-1.fc5.i386 from extras-development unresolved deps: libgnome-menu.so.0 package: flim - 1.14.7-3.noarch from extras-development unresolved deps: apel -jef From dennis at ausil.us Thu Jul 21 03:10:33 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 20 Jul 2005 22:10:33 -0500 Subject: Extras on Sparc Message-ID: <200507202210.33207.dennis@ausil.us> Hi All, Im currently rebuilding all of Fedora extras on Sparc I have one question as to bug tracking. ?Can I use Redhat's Bugzilla, ?and have it so any sparc related bugs for Fedora Extras get assigned to me, or at least make sure package maintainers ?know ?that i can help with sparc related bugs. ? or should i set up my own bugzilla? ? And if Redhats Bugzilla ?can be used ?who should i talk to have it set up? Dennis From dkl at redhat.com Thu Jul 21 03:20:35 2005 From: dkl at redhat.com (Dave Lawrence) Date: Wed, 20 Jul 2005 23:20:35 -0400 Subject: Extras on Sparc In-Reply-To: <200507202210.33207.dennis@ausil.us> References: <200507202210.33207.dennis@ausil.us> Message-ID: <20050721032035.GA4781@redhat.com> Unfortunately this is not completely possible. Bugzilla tracks ownership by component and not by platform having bugs automatically assigned to you instead of the default component owner if the platform is 'sparc' won't work. I can put you on the initial cc list for specific components if they are 'sparc' related components. Dave On Wed, Jul 20, 2005 at 10:10:33PM -0500, Dennis Gilmore claimed: > Hi All, > > Im currently rebuilding all of Fedora extras on Sparc I have one question as > to bug tracking. ?Can I use Redhat's Bugzilla, ?and have it so any sparc > related bugs for Fedora Extras get assigned to me, or at least make sure > package maintainers ?know ?that i can help with sparc related bugs. ? or > should i set up my own bugzilla? ? > > > And if Redhats Bugzilla ?can be used ?who should i talk to have it set up? > > Dennis > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- ------------------------------- David Lawrence Red Hat Quality Assurance ------------------------------- www.redhat.com ftp.redhat.com From dennis at ausil.us Thu Jul 21 03:24:01 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 20 Jul 2005 22:24:01 -0500 Subject: Extras on Sparc In-Reply-To: <20050721032035.GA4781@redhat.com> References: <200507202210.33207.dennis@ausil.us> <20050721032035.GA4781@redhat.com> Message-ID: <200507202224.02241.dennis@ausil.us> Once upon a time Wednesday 20 July 2005 10:20 pm, Dave Lawrence wrote: > Unfortunately this is not completely possible. Bugzilla tracks ownership > by component and not by platform having bugs automatically assigned to you > instead of the default component owner if the platform is 'sparc' won't > work. I can put you on the initial cc list for specific components if they > are 'sparc' related components. > > Dave That would work also. I had a feeling that bugzilla didnt have that fine a control. Dennis From Nicolas.Mailhot at laPoste.net Thu Jul 21 06:18:31 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 21 Jul 2005 08:18:31 +0200 Subject: clamd handicraft work In-Reply-To: <42DEFDCC.30104@redhat.com> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <1121871283.26403.5.camel@proton.cygnusx-1.org> <20050720182958.GA575@osiris.silug.org> <1121909794.31249.4.camel@proton.cygnusx-1.org> <42DEFDCC.30104@redhat.com> Message-ID: <1121926711.8665.5.camel@rousalka.dyndns.org> Le mercredi 20 juillet 2005 ? 15:43 -1000, Warren Togami a ?crit : > I cannot say for certain because I personally have never used amavisd, > but Nathan's reasoning above sounds good. However you are all talking about hypothetical packaging mistakes, since the actual to-be-proposed package : 1. does not duplicate any clamav files 2. adds a clamd.amavis that reads CLAMD_SERVICE=amavisd . /usr/share/clamav/clamd-wrapper So it's doing things how it should -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Thu Jul 21 06:32:52 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 21 Jul 2005 09:32:52 +0300 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <200507210748.23591.symbiont@berlios.de> References: <42D82113.5030005@cora.nwra.com> <1121879387.28256.47.camel@ignacio.lan> <42DEA5DC.7020203@cora.nwra.com> <200507210748.23591.symbiont@berlios.de> Message-ID: <1121927572.14525.272.camel@localhost.localdomain> On Thu, 2005-07-21 at 07:48 +0800, Jeff Pitman wrote: > FWIW, you can BuildRequires: buildsys-macros, if you really want. The > above is yumable. It would not make any sense in the first place, and especially not because even if available "out there", buildsys-macros is not in Extras. From pmatilai at laiskiainen.org Thu Jul 21 06:45:34 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 20 Jul 2005 23:45:34 -0700 (PDT) Subject: libxml++ is old In-Reply-To: <20050720144548.GA29875@redhat.com> References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> <20050720041007.GA2932@redhat.com> <20050720144548.GA29875@redhat.com> Message-ID: On Wed, 20 Jul 2005, Daniel Veillard wrote: > On Wed, Jul 20, 2005 at 10:03:06AM -0400, Konstantin Ryabitsev wrote: >> On 20/07/05, Daniel Veillard wrote: >>>> libxml++ is C++ bindings for libxml/libxml2. >>> >>> Right, well more precisely it is *one* of the C++ bindings for libxml2 >>> though those days it clearly the most popular. The question still remains: >>> what uses it ? If there was really a shortage for maintainers and a need >>> I could try to handle it myself, but I would rather delegate :-) >> >> How hard would it be to create, analogously to libxml/libxml2, >> libxml++ and libxml2++? Does libxml++-2.x live happily alongside >> libxml++-1.x? > > libxml v1 is dead. > the libxml++ jump in numbering isn't as drastic a jump as it was > for libxml. And I would rather avoid keeping dual versions for the > C++ bindings if there is nothing really requiring the old one. So > back to the core question: what is using libxml C++ bindings ? Nothing, AFAICT: [pmatilai at weasel yum-utils]$ ./repoquery.py --whatrequires --alldeps libxml++ libxml++-devel-0:0.26.0-4.x86_64 I packaged libxml++ back in the fedora.us days with *something* in mind but managed to forget what the something was in the process. :) If somebody is interested in the package, feel free to take over, update and do whatever you want with it. - Panu - From pmatilai at laiskiainen.org Thu Jul 21 06:47:43 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 20 Jul 2005 23:47:43 -0700 (PDT) Subject: libxml++ is old In-Reply-To: References: <42DDC919.9010503@redhat.com> <1121832269.28256.40.camel@ignacio.lan> <20050720041007.GA2932@redhat.com> <20050720144548.GA29875@redhat.com> Message-ID: On Wed, 20 Jul 2005, Konstantin Ryabitsev wrote: > On 20/07/05, Daniel Veillard wrote: >> libxml v1 is dead. >> the libxml++ jump in numbering isn't as drastic a jump as it was >> for libxml. And I would rather avoid keeping dual versions for the >> C++ bindings if there is nothing really requiring the old one. So >> back to the core question: what is using libxml C++ bindings ? > > Looks like nothing requires it. I can add this to my collection of > maintained packages, since I need to have it to package granule > anyway. Unless there are other claimants, of course. It's all yours :) Better to have somebody maintain it who actually uses it as well. - Panu - From ville.skytta at iki.fi Thu Jul 21 06:51:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 21 Jul 2005 09:51:25 +0300 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050720194435c82e37@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: <1121928685.14525.274.camel@localhost.localdomain> On Wed, 2005-07-20 at 22:44 -0400, Jeff Spaleta wrote: > package: lft - 2.31-2.i386 from extras-development > unresolved deps: > libpcap.so.0.8.3 I'll take a look. > package: flim - 1.14.7-3.noarch from extras-development > unresolved deps: > apel apel is in the Extras build queue. From paul at city-fan.org Thu Jul 21 07:07:45 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 21 Jul 2005 08:07:45 +0100 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050720194435c82e37@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: <1121929665.25207.395.camel@laurel.intra.city-fan.org> On Wed, 2005-07-20 at 22:44 -0400, Jeff Spaleta wrote: > So on a whim., i ran repoclosure against development and > extras-development. And of course I've got some out-of-sync packages > in the extras tree due to the uptick in activity in rawhide. No great surprise given that rawhide has been active whilst the Extras buildsystem has been undergoing maintenance and hence unavailable for a week or so. > The > question is what to do about broken deps i found? > I'm loath to file individual bugreports manually everytime i get bored > enough to do this run. Are we at the point where we can add an > automated run of this periodicly that notifizes extras package > maintainers about broken deps.. not unsimilar to the rawhide build > report but perhaps not daily. I'd have thought weekly would be fine for notices that go directly to maintainers (who might be on vacation for instance), but daily would be OK for a composite message sent to a list, like the one for the rawhide build report. Paul. -- Paul Howarth From pmatilai at laiskiainen.org Thu Jul 21 07:07:45 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Jul 2005 00:07:45 -0700 (PDT) Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050720194435c82e37@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: On Wed, 20 Jul 2005, Jeff Spaleta wrote: > So on a whim., i ran repoclosure against development and > extras-development. And of course I've got some out-of-sync packages > in the extras tree due to the uptick in activity in rawhide. The > question is what to do about broken deps i found? > I'm loath to file individual bugreports manually everytime i get bored > enough to do this run. Are we at the point where we can add an > automated run of this periodicly that notifizes extras package > maintainers about broken deps.. not unsimilar to the rawhide build > report but perhaps not daily. I think that's a very good idea - weekly perhaps? And not just for development but fc4 (or whatever is supported at the time) as well, see below. > > Here is the output of repoclosure -r development -r extras-development > on my x86 box cleansed to show only relevant items in Extras with > broken deps: ... > package: apt-groupinstall - 0.5.15cnc7-2.i386 from extras-development > unresolved deps: > comps Urgh. That's somewhat problematic, since comps doesn't exist in any repository but get's normally installed by anaconda from base/comps.rpm. To "fix" it either comps would need to be available somewhere else as well (not really an option I guess), or that dependency should be dropped, groupinstall will exit cleanly with error if it's not there. What's more worrisome than extras-devel having broken dependencies is that we have them in fc4-extras as well (at least on x86_64): [pmatilai at weasel yum-utils]$ python repoclosure.py -r base -r extras Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 2 extras base Num Packages in Repos: 3208 package: showimg - 0.9.4.1-2.x86_64 from extras unresolved deps: libexif.so.9()(64bit) package: python-reportlab - 1.19-2.x86_64 from extras unresolved deps: python < 0:2.4 package: octave-devel - 6:2.1.71-9.fc4.x86_64 from extras unresolved deps: octave = 0:2.1.71-9.fc4 package: screem - 0.12.1-1.x86_64 from extras unresolved deps: libdbus-glib-1.so.0()(64bit) libdbus-1.so.0()(64bit) package: gcombust - 1:0.1.55-6.x86_64 from extras unresolved deps: cdlabelgen >= 0:1.5.0 package: gda-postgres - 1:1.2.0-5.x86_64 from extras unresolved deps: libpq.so.3()(64bit) - Panu - From pmatilai at laiskiainen.org Thu Jul 21 07:37:28 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Jul 2005 00:37:28 -0700 (PDT) Subject: Run of repoclosure against core-development and extras-development In-Reply-To: References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: On Thu, 21 Jul 2005, Panu Matilainen wrote: >> package: apt-groupinstall - 0.5.15cnc7-2.i386 from extras-development >> unresolved deps: >> comps > > Urgh. That's somewhat problematic, since comps doesn't exist in any > repository but get's normally installed by anaconda from base/comps.rpm. To > "fix" it either comps would need to be available somewhere else as well (not > really an option I guess), or that dependency should be dropped, groupinstall > will exit cleanly with error if it's not there. Hmm... comps package *was* in the repo for at least FC4, whether it's gotten removed temporarily or permanently from the development tree I don't know. - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 21 07:45:02 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 21 Jul 2005 09:45:02 +0200 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050720194435c82e37@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: <20050721094502.56f5ced7@python2> Jeff Spaleta wrote : > package: gcombust - 1:0.1.55-6.i386 from extras-development > unresolved deps: > cdlabelgen >= 0:1.5.0 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159127 Didn't get an answer from Harald, so I guess I should simply do what's necessary to get the package cleaned up and build. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.48 0.44 0.30 From oliver at linux-kernel.at Thu Jul 21 07:54:20 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 21 Jul 2005 09:54:20 +0200 Subject: Wording of "Previously in Core" Procedure In-Reply-To: <42DEF899.1010205@redhat.com> References: <42DEF899.1010205@redhat.com> Message-ID: <42DF54AC.3080609@linux-kernel.at> On 07/21/2005 03:21 AM, Warren Togami wrote: > I will be adding the exception that we had been following during the > past few months to the NewPackageProcess. Maybe the wording will need > to be cleaned up a bit, and I am not exactly sure where to add it to the > current page. Please reply with suggestions and questions. > > > "If the package has been in a previous Fedora Core stable release but it > has been subsequently removed, then it requires no review to be imported > into Fedora Extras. Existing Extras contributors may claim ownership by > posting to fedora-extras-list with the package name in the Subject, > importing the original RH package, then proceding to make improvements > in CVS from that baseline." > > > I explicitly state "Existing Extras contributors" here because adoption > of an existing package written by someone else is most often never > enough of an indicator to the sponsors if that new potential contributor > truly understands packaging and has read the guidelines. One of the > things decided upon at the FUDCON2 planning meeting was that new members > can become sponsored only after one or more of their package submissions > has been reviewed and approved. After this point a sponsor member can > determine if it is the right thing to grant membership. For me this wording seems fine and is acknowleged fully! However, I'm not sure if it's really a good idea to let 'old packages' go into FE without review, but let's see what future brings to us... I'm sure you have thought about this and discussed it... My 2 cent, Oliver From andreas.bierfert at lowlatency.de Thu Jul 21 08:07:07 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 21 Jul 2005 10:07:07 +0200 Subject: Request for review: koffice In-Reply-To: <42DEF277.1050507@redhat.com> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> Message-ID: <42DF57AB.8030304@lowlatency.de> Warren Togami wrote: > BTW where is the latest version of your package? I have no idea where > to download it. The Epoch related changes suggested by Rex earlier in > the thread looked potentially wrong to me, so I want to see the latest > version of the package in order to test it. Due to all the lang packages I did not put explicit URLs up... you can get all srpms at http://fedora.lowlatency.de/review/ . Let me know what you think. - Andreas From andreas.bierfert at lowlatency.de Thu Jul 21 08:09:08 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 21 Jul 2005 10:09:08 +0200 Subject: Request for review: koffice In-Reply-To: <42DEEF89.8080907@redhat.com> References: <42C46C17.3050805@lowlatency.de> <42DED416.3010609@lowlatency.de> <200507201751.05617.dennis@ausil.us> <42DEEF89.8080907@redhat.com> Message-ID: <42DF5824.4070607@lowlatency.de> Warren Togami wrote: > Than has done absolutely nothing wrong. Red Hat engineers AFAIK have > never bypassed any established process. We have however considered > packages previously in Core but dropped as not requiring review before > import into Extras. If this has not been noted in the procedures then > THAT is my fault. Not a problem... it just would have been nice to get a notice on this thread... that is all. > Dennis if your package is superior to the original Red Hat package, then > you are welcome to replace whatever is in CVS and become the new > maintainer. I'll take a look at your package now myself. If it is the FC3 package than one bonus could be the ooo like split up of koffice... - Andreas From wtogami at redhat.com Thu Jul 21 08:51:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 22:51:53 -1000 Subject: Request for review: koffice In-Reply-To: <42DF57AB.8030304@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> <42DF57AB.8030304@lowlatency.de> Message-ID: <42DF6229.8090009@redhat.com> Andreas Bierfert wrote: > Warren Togami wrote: > >>BTW where is the latest version of your package? I have no idea where >>to download it. The Epoch related changes suggested by Rex earlier in >>the thread looked potentially wrong to me, so I want to see the latest >>version of the package in order to test it. > > > Due to all the lang packages I did not put explicit URLs up... you can > get all srpms at http://fedora.lowlatency.de/review/ . Let me know what > you think. > Yikes! Do you really want to maintain those many SRPMS? It would make it much easier to maintain if all language packs are in one SRPM, which outputs the many RPMS? It only makes sense to maintain them as separate SRPMS if the different languages have their own version numbers, and individual languages update independently. This does not appear to be the case. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Jul 21 09:34:09 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Jul 2005 23:34:09 -1000 Subject: Request for review: koffice In-Reply-To: <42DF57AB.8030304@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> <42DF57AB.8030304@lowlatency.de> Message-ID: <42DF6C11.7080409@redhat.com> Andreas Bierfert wrote: > Warren Togami wrote: > >>BTW where is the latest version of your package? I have no idea where >>to download it. The Epoch related changes suggested by Rex earlier in >>the thread looked potentially wrong to me, so I want to see the latest >>version of the package in order to test it. > > > Due to all the lang packages I did not put explicit URLs up... you can > get all srpms at http://fedora.lowlatency.de/review/ . Let me know what > you think. > Just confirming what I see, you managed to get rid of the Epoch by getting rid of the binary RPM called "koffice" and "koffice-i18n" and replacing it with koffice-core and many other sub-packages? I never seen that before. I suppose that works ... creative way to get rid of the Epoch. Not sure if we want to encourage this in other packages though. I suppose the -core precedent matches openoffice.org so this is OK in this case. What happens if someone using FC3 does a yum upgrade to FC4, does this koffice automatically pull in koffice-core and equivalent functionality that was working before? Is koffice-core useful for anything on its own? Not a huge problem... but it sounds like a lot of work for a user to install the entire suite. Maybe koffice-core would be more accurately named koffice-libs? Just an idea. It appears that 1.4b is available upstream, with more bug fixes? Warren Togami wtogami at redhat.com From symbiont at berlios.de Thu Jul 21 10:22:32 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 21 Jul 2005 18:22:32 +0800 Subject: Request for review: koffice In-Reply-To: <42DF6C11.7080409@redhat.com> References: <42C46C17.3050805@lowlatency.de> <42DF57AB.8030304@lowlatency.de> <42DF6C11.7080409@redhat.com> Message-ID: <200507211822.32303.symbiont@berlios.de> On Thursday 21 July 2005 17:34, Warren Togami wrote: > What happens if someone using FC3 does a yum upgrade to FC4, does > this koffice automatically pull in koffice-core and equivalent > functionality that was working before? Obsoletes > Is koffice-core useful for anything on its own? ?Not a huge > problem... but it sounds like a lot of work for a user to install the > entire suite. A koffice virtual can be created to Requires everything (except i18n of course). -- -jeff From bugs.michael at gmx.net Thu Jul 21 11:40:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 21 Jul 2005 13:40:48 +0200 Subject: Request for review: koffice In-Reply-To: <42DEF277.1050507@redhat.com> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> Message-ID: <20050721134048.1e2ceb5e.bugs.michael@gmx.net> On Wed, 20 Jul 2005 14:55:19 -1000, Warren Togami wrote: > (You also did not need review to import it in the first place, because > it was previously in Core. It was my mistake that this was not noted in > the procedures earlier. Both RH engineers and community contributors > were following this exception during the past few months.) It's noted in the process docs for a long time. Quote: For packages included in and removed from a previous version of Fedora Core, generally no explicit approval is needed for restoring the package in Fedora Extras (unless legal/licencing issues were the reason for removal), but do notify fedora-extras-list. And I think we've seen quite some notifications on extras list prior to cvs imports of old Core packages. From bugs.michael at gmx.net Thu Jul 21 11:51:08 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 21 Jul 2005 13:51:08 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <1121908345.2172.91.camel@dch.TQMcube.com> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> <1121811403.6862.122.camel@serendipity.dogma.lan> <20050720015233.1fb439e8.bugs.michael@gmx.net> <1121900094.6862.213.camel@serendipity.dogma.lan> <1121908345.2172.91.camel@dch.TQMcube.com> Message-ID: <20050721135108.50196346.bugs.michael@gmx.net> On Wed, 20 Jul 2005 21:12:25 -0400, David Cary Hart wrote: > On Thu, 2005-07-21 at 00:54 +0200, Alexander Dalloz wrote: > > I was following or even tried to follow those instructions. > > Unfortunately the CVSSyncNeeded page was either much too obvious, I am > > too brain dead or a mixture of both, so that I didn't see what to do > > exacty. With help from Elliot in IRC I now see that the wiki is not only > > the place of the documentation but too used for Fedora processes, such > > like the branch creation request log. > > While talking to Elliot he was so kind and created the FC3 and FC4 > > branches for pam_abl for me. > > As pam_abl was reviewed and approved by Oliver Falk last Friday based on > > the src.rpm, there seems to be no real reason why another review is > > required now based on CVS info. At least I did understand Elliot in this > > way. So if nobody protests I will soon request a build for devel, FC4 > > and FC3. > > > Your post gives me hope that I am not such a mindless idiot. I am going > to compare where I am at with leafnode with the documentation one more > time tomorrow and then cry for help if it's still incomprehensible. >From the perspective of "sponsors", we can only offer help where questions are raised or where mistakes/accidents happen. Personally, I try to cover many answers to questions I'm asked privately in the Wiki. The Wiki pages should not become too complex, however, as with every additional paragraph of text to read, it gives the false impression that there are too many things to consider. This scares off potential contributors. (And who really revisits Wiki pages to check for changes?) The current situation with the work on the new build system most likely is the most confusing thing, as packagers don't get any status feedback for their build requests. From bugs.michael at gmx.net Thu Jul 21 11:53:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 21 Jul 2005 13:53:50 +0200 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050720194435c82e37@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: <20050721135350.799be3c8.bugs.michael@gmx.net> On Wed, 20 Jul 2005 22:44:08 -0400, Jeff Spaleta wrote: > package: showimg - 0.9.4.1-2.i386 from extras-development > unresolved deps: > libexif.so.9 This is in bugzilla already. From dennis at ausil.us Thu Jul 21 11:53:54 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 21 Jul 2005 06:53:54 -0500 Subject: Request for review: koffice In-Reply-To: <20050721134048.1e2ceb5e.bugs.michael@gmx.net> References: <42C46C17.3050805@lowlatency.de> <42DEF277.1050507@redhat.com> <20050721134048.1e2ceb5e.bugs.michael@gmx.net> Message-ID: <200507210653.55478.dennis@ausil.us> Once upon a time Thursday 21 July 2005 6:40 am, Michael Schwendt wrote: > On Wed, 20 Jul 2005 14:55:19 -1000, Warren Togami wrote: > > (You also did not need review to import it in the first place, because > > it was previously in Core. It was my mistake that this was not noted in > > the procedures earlier. Both RH engineers and community contributors > > were following this exception during the past few months.) > > It's noted in the process docs for a long time. Quote: > > For packages included in and removed from a previous version of Fedora > Core, generally no explicit approval is needed for restoring the package > in Fedora Extras (unless legal/licencing issues were the reason for > removal), but do notify fedora-extras-list. > > And I think we've seen quite some notifications on extras list prior > to cvs imports of old Core packages. Yes there has been but in this case there wasn't. do we want the precedent changed? Than has never once posted to the fedora-extras-list according to google. I have no problem with him maintaining koffice. i have a problem with him just importing the package into cvs without having said he was going to do it especially after the recent discussions on packaging koffice on the list. Dennis From alex at dalloz.de Thu Jul 21 12:22:41 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Thu, 21 Jul 2005 14:22:41 +0200 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050721135108.50196346.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> <1121811403.6862.122.camel@serendipity.dogma.lan> <20050720015233.1fb439e8.bugs.michael@gmx.net> <1121900094.6862.213.camel@serendipity.dogma.lan> <1121908345.2172.91.camel@dch.TQMcube.com> <20050721135108.50196346.bugs.michael@gmx.net> Message-ID: <1121948561.6862.259.camel@serendipity.dogma.lan> Am Do, den 21.07.2005 schrieb Michael Schwendt um 13:51: > >From the perspective of "sponsors", we can only offer help where > questions are raised or where mistakes/accidents happen. Personally, > I try to cover many answers to questions I'm asked privately in the I understand that and found you in special, but other Extras fellows as well, always willing to help and to answer. > Wiki. The Wiki pages should not become too complex, however, as > with every additional paragraph of text to read, it gives the false > impression that there are too many things to consider. This scares > off potential contributors. (And who really revisits Wiki pages to > check for changes?) The current situation with the work on the > new build system most likely is the most confusing thing, as packagers > don't get any status feedback for their build requests. There is the recent changes page in our Wiki http://www.fedoraproject.org/wiki/RecentChanges but maybe it makes sense to have an RSS feed about important things? Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Thu Jul 21 13:00:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Jul 2005 09:00:29 -0400 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: <604aa791050721060012d67078@mail.gmail.com> On 7/21/05, Panu Matilainen wrote: > What's more worrisome than extras-devel having broken dependencies is that > we have them in fc4-extras as well (at least on x86_64): you have to be a little descriminating and double-check that the dep problem you are seeing is from the "newest" package in the tree. For example the newest version of octave-devel in extras is 2.1.71-12, which doesn't have a problem. repomanage doesn't yet have a facility to ignore "old" packages in a tree. And i am very much against making Extras a fully rolling tree like rawhide and I believe we need to keep old versions of packages in a tree around "long enough" to make sure the new update doesn't have a horrible problem so people can revert back to the older package without having to rely on a cached copy. If repomanage could magically gain the ability to ignore old versions of a package in a tree, this would clean up several of the dep errors you saw.. like the octave-devel error and the screem error. -jef From rdieter at math.unl.edu Thu Jul 21 13:37:34 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Jul 2005 08:37:34 -0500 Subject: Request for review: koffice In-Reply-To: <42DF6229.8090009@redhat.com> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> <42DF57AB.8030304@lowlatency.de> <42DF6229.8090009@redhat.com> Message-ID: Warren Togami wrote: > Andreas Bierfert wrote: > >> Warren Togami wrote: >> >>> BTW where is the latest version of your package? I have no idea where >>> to download it. The Epoch related changes suggested by Rex earlier in >>> the thread looked potentially wrong to me, so I want to see the latest >>> version of the package in order to test it. >> >> >> >> Due to all the lang packages I did not put explicit URLs up... you can >> get all srpms at http://fedora.lowlatency.de/review/ . Let me know what >> you think. >> > > Yikes! Do you really want to maintain those many SRPMS? > > It would make it much easier to maintain if all language packs are in > one SRPM, which outputs the many RPMS? IMO, I disagree. Say you have a bug in *one* language pack. If packaged monolithically, a rebuild of *all* of them would result. -- Rex From fedora at tqmcube.com Thu Jul 21 13:50:26 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Thu, 21 Jul 2005 09:50:26 -0400 Subject: Request for a sponsor and a review of: pam_abl In-Reply-To: <20050721135108.50196346.bugs.michael@gmx.net> References: <1121100153.22665.295.camel@serendipity.dogma.lan> <1121291752.1574.393.camel@serendipity.dogma.lan> <42D769C8.8070808@linux-kernel.at> <1121430052.27608.60.camel@serendipity.dogma.lan> <42D7B1C3.9060009@linux-kernel.at> <1121805297.6862.81.camel@serendipity.dogma.lan> <20050719231744.2be2165f.bugs.michael@gmx.net> <1121811403.6862.122.camel@serendipity.dogma.lan> <20050720015233.1fb439e8.bugs.michael@gmx.net> <1121900094.6862.213.camel@serendipity.dogma.lan> <1121908345.2172.91.camel@dch.TQMcube.com> <20050721135108.50196346.bugs.michael@gmx.net> Message-ID: <1121953826.4375.5.camel@dch.TQMcube.com> On Thu, 2005-07-21 at 13:51 +0200, Michael Schwendt wrote: > From the perspective of "sponsors", we can only offer help where > questions are raised or where mistakes/accidents happen. Personally, > I try to cover many answers to questions I'm asked privately in the > Wiki. The Wiki pages should not become too complex, however, as > with every additional paragraph of text to read, it gives the false > impression that there are too many things to consider. This scares > off potential contributors. (And who really revisits Wiki pages to > check for changes?) The current situation with the work on the > new build system most likely is the most confusing thing, as packagers > don't get any status feedback for their build requests. Not to worry. Struggling through was MY choice in an effort to gain more understanding. There are several packages that I would like to bring into FE so the first one has to serve as my tutorial. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From fedora at tqmcube.com Thu Jul 21 14:00:52 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Thu, 21 Jul 2005 10:00:52 -0400 Subject: Request for review: koffice In-Reply-To: <200507210653.55478.dennis@ausil.us> References: <42C46C17.3050805@lowlatency.de> <42DEF277.1050507@redhat.com> <20050721134048.1e2ceb5e.bugs.michael@gmx.net> <200507210653.55478.dennis@ausil.us> Message-ID: <1121954452.4375.15.camel@dch.TQMcube.com> On Thu, 2005-07-21 at 06:53 -0500, Dennis Gilmore wrote: > Yes there has been but in this case there wasn't. do we want the precedent > changed? > > Than has never once posted to the fedora-extras-list according to google. I > have no problem with him maintaining koffice. i have a problem with him > just importing the package into cvs without having said he was going to do > it especially after the recent discussions on packaging koffice on the list. JMO (I am a Training/Education executive by profession); There is a great deal of ambiguity (at least for me) in separating process, practice and policy. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From jspaleta at gmail.com Thu Jul 21 14:25:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Jul 2005 10:25:20 -0400 Subject: Request for review: koffice In-Reply-To: <200507211822.32303.symbiont@berlios.de> References: <42C46C17.3050805@lowlatency.de> <42DF57AB.8030304@lowlatency.de> <42DF6C11.7080409@redhat.com> <200507211822.32303.symbiont@berlios.de> Message-ID: <604aa791050721072549e1a127@mail.gmail.com> On 7/21/05, Jeff Pitman wrote: > A koffice virtual can be created to Requires everything (except i18n of > course). uhm... how about defining a comps group... and encouraging people to install the group via groupinstall operations. -jef From rc040203 at freenet.de Thu Jul 21 14:30:24 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Jul 2005 16:30:24 +0200 Subject: Request for review: koffice In-Reply-To: <604aa791050721072549e1a127@mail.gmail.com> References: <42C46C17.3050805@lowlatency.de> <42DF57AB.8030304@lowlatency.de> <42DF6C11.7080409@redhat.com> <200507211822.32303.symbiont@berlios.de> <604aa791050721072549e1a127@mail.gmail.com> Message-ID: <1121956224.2015.234.camel@mccallum.corsepiu.local> On Thu, 2005-07-21 at 10:25 -0400, Jeff Spaleta wrote: > On 7/21/05, Jeff Pitman wrote: > > A koffice virtual can be created to Requires everything (except i18n of > > course). > > uhm... how about defining a comps group... and encouraging people to > install the group via groupinstall operations. Nope. RPM-wise comps is not of any importance. Ralf From andreas.bierfert at lowlatency.de Thu Jul 21 14:47:40 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 21 Jul 2005 16:47:40 +0200 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> <42DF57AB.8030304@lowlatency.de> <42DF6229.8090009@redhat.com> Message-ID: <42DFB58C.9050506@lowlatency.de> I don't care one or the other way... just as long as we agree. (i) one srpm for all of koffice (ii) one srpm for koffice and one for koffice-lang stuff (iii) one srpm for koffice and lots of other srpms for lang stuff I would choose (ii) because it does not jam the cvs to much but keeps things a little bit more organized. Even with the downside of upgrading all installed lang files if only one lang source changes. - Andreas From joost at cnoc.nl Thu Jul 21 15:14:21 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Thu, 21 Jul 2005 17:14:21 +0200 Subject: Request for sponsor and review of: lazarus and fpc Message-ID: <1121958861.18178.29.camel@joost> Hi all, Some time ago Jens Petersen helped me a lot with creating a package for freepascal (fpc 2.0.0) but I didn't succeed to find a sponsor thus far. In the meantime an IDE which works with freepascal 2.0.0 is available. Maybe someone want to review the lazarus package, and even sponsor me so I can commit fpc and lazarus into the cvs. Lazarus: Lazarus is a free and opensource RAD tool for freepascal using the lazarus component library - LCL, which is also included in this package. fpc: Freepascal is a free 32/64bit Pascal Compiler. It comes with a run-time library fully compatible with Turbo Pascal 7.0 and nearly Delphi compatible. Some extensions are added to the language, like function overloading. Shared libraries can be linked. This package contains commandline compiler and utils. Provided units are the runtime library (RTL), free component library (FCL) and bindings for among others gtk1, gtk2, ncurses, zlib, mysql, postgres and ibase. All needed files can be found here: http://www.cnoc.nl/fpc http://www.cnoc.nl/fpc/fpc-2.0.0-0.6.src.rpm http://www.cnoc.nl/fpc/lazarus-0.9.8-0.1.src.rpm especially Lazarus is worth a view. It's the most advanced IDE which works on Linux that I know of. Regards, Joost From pmatilai at laiskiainen.org Thu Jul 21 16:49:17 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Jul 2005 09:49:17 -0700 (PDT) Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050721060012d67078@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> <604aa791050721060012d67078@mail.gmail.com> Message-ID: On Thu, 21 Jul 2005, Jeff Spaleta wrote: > On 7/21/05, Panu Matilainen wrote: >> What's more worrisome than extras-devel having broken dependencies is that >> we have them in fc4-extras as well (at least on x86_64): > > you have to be a little descriminating and double-check that the dep > problem you are seeing is from the "newest" package in the tree. For > example > the newest version of octave-devel in extras is 2.1.71-12, which > doesn't have a problem. Ah, ok, I didn't check for that at all. > repomanage doesn't yet have a facility to ignore "old" packages in a > tree. And i am very much against making Extras a fully rolling tree > like rawhide and I believe we need to keep old versions of packages in > a tree around "long enough" to make sure the new update doesn't have a > horrible problem so people can revert back to the older package > without having to rely on a cached copy. I'm still of the opinion that extras should have a separate "release tree" and updates (+ updates-testing) tree just like FC has, even if the "release" of FE for some version doesn't happen the very same date as FC does. Rolling trees make me ... nervous. With a "release tree" you can be sure there's at least one known version of a given software with known behavior, buggy or not. With rolling trees you never know. > If repomanage could magically gain the ability to ignore old versions > of a package in a tree, this would clean up several of the dep errors > you saw.. like the octave-devel error and the screem error. Yup, that'd be a nice addition to repoclosure. I'll try to remember that the next time I'm bored and looking for something to hack on :) - Panu - From tibbs at math.uh.edu Thu Jul 21 16:59:17 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 21 Jul 2005 11:59:17 -0500 Subject: Request for additional review: denyhosts Message-ID: The denyhosts package has been in extras for a while now, but a recently released version changed from "put the executable in /usr/bin" to the standard Python setup system ("python ./setup.py"). Since I'm not completely familiar with the latter, I figure I'd ask for input. It's in CVS devel branch, and a spec and src.rpm are in http://www.math.uh.edu/~tibbs/rpms/denyhosts The only thing I really have a question about is the fact that the Python setup process seems to install documentation in /usr/share/denyhosts, while the %doc directive places them in /usr/share/doc/denyhosts-0.8.0 and the result is two copies of the documentation. What's the accepted way of handling this? - J< From jspaleta at gmail.com Thu Jul 21 17:12:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Jul 2005 13:12:09 -0400 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: References: <604aa791050720194435c82e37@mail.gmail.com> <604aa791050721060012d67078@mail.gmail.com> Message-ID: <604aa791050721101256f2341f@mail.gmail.com> On 7/21/05, Panu Matilainen wrote: > I'm still of the opinion that extras should have a separate "release tree" > and updates (+ updates-testing) tree just like FC has, even if the > "release" of FE for some version doesn't happen the very same date as FC > does. Rolling trees make me ... nervous. I'm not going to disgree with your opinion. But if Extras is going to continue to roll I will continue to demand keeping older versions of packages around for "long enough." > With a "release tree" you can be > sure there's at least one known version of a given software with known > behavior, buggy or not. With rolling trees you never know. I think there are other advantages as well in terms of how to make it easy for 3rd party vendors to provide install media and update media sets for extras... when we are ready to deal with that issue directly. > Yup, that'd be a nice addition to repoclosure. I'll try to remember that > the next time I'm bored and looking for something to hack on :) Dancing bear hash bars are of higher importance. -jef From jspaleta at gmail.com Thu Jul 21 17:27:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Jul 2005 13:27:19 -0400 Subject: Request for review: koffice In-Reply-To: <1121956224.2015.234.camel@mccallum.corsepiu.local> References: <42C46C17.3050805@lowlatency.de> <42DF57AB.8030304@lowlatency.de> <42DF6C11.7080409@redhat.com> <200507211822.32303.symbiont@berlios.de> <604aa791050721072549e1a127@mail.gmail.com> <1121956224.2015.234.camel@mccallum.corsepiu.local> Message-ID: <604aa7910507211027490f2d7b@mail.gmail.com> On 7/21/05, Ralf Corsepius wrote: > Nope. RPM-wise comps is not of any importance. My reading of pittman's answer was that he wanted to create a virtual package named "kdesktop" designed only to pull in other packages as requirments without any file payload itself. While this is technically feasible to do... its something I'm pretty sure is not actively encouraged as a solution to problems of this nature. openoffice.org in Core certaintly doesn't have a virtual package in Core that drags all the components in as requirements. If there are a group of packages that interact together to create a large suite or environment.. they are defined as a group and installed via group operations. We do this with group XFCE in Extras to provide all the peices that make up a typical xfce environment and we do this with the Office/Productivity group in core to get all the pieces of openoffice.org installed, as well as a few other items. I don't see why there is a need here to delibrately create virtual package for koffice to shortcut the process of group definitions and installs. -jef From ed at eh3.com Thu Jul 21 17:44:09 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 21 Jul 2005 13:44:09 -0400 Subject: Sponsor and review request: opendap, librx --> *and* NCO review request In-Reply-To: <1121732811.32518.88.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1119154931.10309.8.camel@localhost.localdomain> <1119201019.9216.71.camel@ernie> <1121732811.32518.88.camel@localhost.localdomain> Message-ID: <1121967849.5322.40.camel@ernie> On Mon, 2005-07-18 at 19:26 -0500, Tom 'spot' Callaway wrote: > Review: (nco-3.0.1-1) > > Really minor issue of the license file text is the only blocker, please > fix it before you request a build. APPROVED. Hi Spot, Thank you for the review! And could you please request a build of opendap in order to get a new version out that doesn't have the PIC issue w/ nco? Or, may I have your permission to do it? thanks again! Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From wtogami at redhat.com Thu Jul 21 18:43:22 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Jul 2005 08:43:22 -1000 Subject: Request for review: koffice In-Reply-To: <42DFB58C.9050506@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> <42DF57AB.8030304@lowlatency.de> <42DF6229.8090009@redhat.com> <42DFB58C.9050506@lowlatency.de> Message-ID: <42DFECCA.5050905@redhat.com> Andreas Bierfert wrote: > I don't care one or the other way... just as long as we agree. > > (i) one srpm for all of koffice > > (ii) one srpm for koffice and one for koffice-lang stuff > > (iii) one srpm for koffice and lots of other srpms for lang stuff > > I would choose (ii) because it does not jam the cvs to much but keeps > things a little bit more organized. Even with the downside of upgrading > all installed lang files if only one lang source changes. > (ii) reflects reality while (iii) does not. When koffice has new versions, it will have new/changed strings and ALL language packs need to be updated anyway. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Jul 21 18:47:25 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Jul 2005 08:47:25 -1000 Subject: Request for review: koffice In-Reply-To: <200507211822.32303.symbiont@berlios.de> References: <42C46C17.3050805@lowlatency.de> <42DF57AB.8030304@lowlatency.de> <42DF6C11.7080409@redhat.com> <200507211822.32303.symbiont@berlios.de> Message-ID: <42DFEDBD.4080904@redhat.com> Jeff Pitman wrote: > On Thursday 21 July 2005 17:34, Warren Togami wrote: > >>What happens if someone using FC3 does a yum upgrade to FC4, does >>this koffice automatically pull in koffice-core and equivalent >>functionality that was working before? > > > Obsoletes Does Obsoletes automatically pull in koffice-core into the upgrade transaction? > > >>Is koffice-core useful for anything on its own? Not a huge >>problem... but it sounds like a lot of work for a user to install the >>entire suite. > > > A koffice virtual can be created to Requires everything (except i18n of > course). > How about this idea, koffice-suite (another sub-package) contains nothing, but Obsoletes koffice and koffice-i18n and Requires all of the koffice applications. If Obsoletes causes replacement during upgrade, then the entire suite is installed during an upgrade. If the sysadmin wants to cut it down, uninstall koffice-suite (which effects nothinge else) and remove other sub-packages to suite tastes? Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Thu Jul 21 18:53:33 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 21 Jul 2005 21:53:33 +0300 Subject: New Request for Review: istanbul - Now under new management In-Reply-To: <604aa791050720142012f60201@mail.gmail.com> References: <604aa791050720142012f60201@mail.gmail.com> Message-ID: <1121972013.24371.4.camel@localhost.localdomain> On Wed, 2005-07-20 at 17:20 -0400, Jeff Spaleta wrote: > rpmlint istanbul-0.1.1-3.i386.rpm returns: > E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/README > E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/AUTHORS > E: istanbul zero-length /usr/share/doc/istanbul-0.1.1/NEWS > > all 3 files are zero-length in the source tarball? Keep them in the > rpm or exclude them? Exclude. Usefulness of zero-length docs is actually less than zero. > W: istanbul empty-%post > Should i remove the empty postun and post sections from the spec? Remove. Roughly the same applies as in above. From tcallawa at redhat.com Thu Jul 21 18:55:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 21 Jul 2005 13:55:08 -0500 Subject: Sponsor and review request: opendap, librx --> *and* NCO review request In-Reply-To: <1121967849.5322.40.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1119154931.10309.8.camel@localhost.localdomain> <1119201019.9216.71.camel@ernie> <1121732811.32518.88.camel@localhost.localdomain> <1121967849.5322.40.camel@ernie> Message-ID: <1121972108.3111.2.camel@localhost.localdomain> On Thu, 2005-07-21 at 13:44 -0400, Ed Hill wrote: > On Mon, 2005-07-18 at 19:26 -0500, Tom 'spot' Callaway wrote: > > Review: (nco-3.0.1-1) > > > > Really minor issue of the license file text is the only blocker, please > > fix it before you request a build. APPROVED. > > > Hi Spot, > > Thank you for the review! > > And could you please request a build of opendap in order to get a new > version out that doesn't have the PIC issue w/ nco? Or, may I have your > permission to do it? I was waiting for the buildsystem to come back up. Is it alive again? :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at phy.duke.edu Thu Jul 21 18:59:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 21 Jul 2005 14:59:11 -0400 Subject: Sponsor and review request: opendap, librx --> *and* NCO review request In-Reply-To: <1121972108.3111.2.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1119154931.10309.8.camel@localhost.localdomain> <1119201019.9216.71.camel@ernie> <1121732811.32518.88.camel@localhost.localdomain> <1121967849.5322.40.camel@ernie> <1121972108.3111.2.camel@localhost.localdomain> Message-ID: <1121972351.17523.0.camel@cutter> On Thu, 2005-07-21 at 13:55 -0500, Tom 'spot' Callaway wrote: > On Thu, 2005-07-21 at 13:44 -0400, Ed Hill wrote: > > On Mon, 2005-07-18 at 19:26 -0500, Tom 'spot' Callaway wrote: > > > Review: (nco-3.0.1-1) > > > > > > Really minor issue of the license file text is the only blocker, please > > > fix it before you request a build. APPROVED. > > > > > > Hi Spot, > > > > Thank you for the review! > > > > And could you please request a build of opendap in order to get a new > > version out that doesn't have the PIC issue w/ nco? Or, may I have your > > permission to do it? > > I was waiting for the buildsystem to come back up. Is it alive again? :) no. -sv From ed at eh3.com Thu Jul 21 19:27:55 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 21 Jul 2005 15:27:55 -0400 Subject: Sponsor and review request: opendap, librx --> *and* NCO review request In-Reply-To: <1121972351.17523.0.camel@cutter> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <1119141334.9216.40.camel@ernie> <1119154931.10309.8.camel@localhost.localdomain> <1119201019.9216.71.camel@ernie> <1121732811.32518.88.camel@localhost.localdomain> <1121967849.5322.40.camel@ernie> <1121972108.3111.2.camel@localhost.localdomain> <1121972351.17523.0.camel@cutter> Message-ID: <1121974075.5322.64.camel@ernie> On Thu, 2005-07-21 at 14:59 -0400, seth vidal wrote: > On Thu, 2005-07-21 at 13:55 -0500, Tom 'spot' Callaway wrote: > > > > I was waiting for the buildsystem to come back up. Is it alive again? :) > > no. Thank you for the update! And my apologies for missing the last 1+ weeks of emails -- have been on vacation and just dug through the archives and found the relevant ones that I probably should have deleted *after* reading them.... :-/ Ed (who will watch closely for the its-OK-to-try-the-new-build-system email announcement) -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From ivazquez at ivazquez.net Thu Jul 21 20:19:19 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Jul 2005 16:19:19 -0400 Subject: Request for additional review: denyhosts In-Reply-To: References: Message-ID: <1121977159.24638.2.camel@ignacio.lan> On Thu, 2005-07-21 at 11:59 -0500, Jason L Tibbitts III wrote: > The denyhosts package has been in extras for a while now, but a > recently released version changed from "put the executable in > /usr/bin" to the standard Python setup system ("python ./setup.py"). > Since I'm not completely familiar with the latter, I figure I'd ask > for input. > > It's in CVS devel branch, and a spec and src.rpm are in > http://www.math.uh.edu/~tibbs/rpms/denyhosts > > The only thing I really have a question about is the fact that the > Python setup process seems to install documentation in > /usr/share/denyhosts, while the %doc directive places them in > /usr/share/doc/denyhosts-0.8.0 and the result is two copies of the > documentation. > > What's the accepted way of handling this? *boggles* Who the heck puts setup.py in data_files? Anyways, the attached patch should fix this. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: denyhosts-0.8.0-docs.patch Type: text/x-patch Size: 674 bytes Desc: not available URL: -------------- 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 andreas.bierfert at lowlatency.de Thu Jul 21 20:19:39 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 21 Jul 2005 22:19:39 +0200 Subject: Request for review: koffice In-Reply-To: <42DFECCA.5050905@redhat.com> References: <42C46C17.3050805@lowlatency.de> <1120226939.8990.166.camel@localhost.localdomain> <42C5C641.6000908@lowlatency.de> <42CAFFD8.2020101@lowlatency.de> <0MKwh2-1DqE1P3ZZi-0003pI@mrelayeu.kundenserver.de> <42CD03F8.5040707@lowlatency.de> <0MKwtQ-1DqaGp37F0-0001C1@mrelayeu.kundenserver.de> <42CD9CB0.80209@lowlatency.de> <42DEF277.1050507@redhat.com> <42DF57AB.8030304@lowlatency.de> <42DF6229.8090009@redhat.com> <42DFB58C.9050506@lowlatency.de> <42DFECCA.5050905@redhat.com> Message-ID: <42E0035B.90201@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren Togami wrote: > (ii) reflects reality while (iii) does not. When koffice has new > versions, it will have new/changed strings and ALL language packs need > to be updated anyway. Ok I will go with (ii) on this one. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC4ANbQEQyPsWM8csRAqUkAJ99C10w+WD2tWU95wk1D6OYzvA8agCfYVbc 2STlazDl4yA+Ist5+3X+Un4= =q9DI -----END PGP SIGNATURE----- From andreas.bierfert at lowlatency.de Thu Jul 21 20:23:23 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 21 Jul 2005 22:23:23 +0200 Subject: Request for review: koffice In-Reply-To: <42DFEDBD.4080904@redhat.com> References: <42C46C17.3050805@lowlatency.de> <42DF57AB.8030304@lowlatency.de> <42DF6C11.7080409@redhat.com> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> Message-ID: <42E0043B.5020200@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren Togami wrote: > How about this idea, koffice-suite (another sub-package) contains > nothing, but Obsoletes koffice and koffice-i18n and Requires all of the > koffice applications. If Obsoletes causes replacement during upgrade, > then the entire suite is installed during an upgrade. Sounds like a good solution. > If the sysadmin wants to cut it down, uninstall koffice-suite (which > effects nothinge else) and remove other sub-packages to suite tastes? Yes, I would want such a upgrade path. Loosing applications due to upgrade stuff is not good but cutting down after should not be a problem. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC4AQ7QEQyPsWM8csRAhy0AKC8BHpR/UV2fXYaFxqjccBw8K4DcwCgm9Gw v+h2LcuM2OCPVer3SCPa4gY= =GSDZ -----END PGP SIGNATURE----- From steve at silug.org Thu Jul 21 20:30:57 2005 From: steve at silug.org (Steven Pritchard) Date: Thu, 21 Jul 2005 15:30:57 -0500 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <52797.192.54.193.37.1121788363.squirrel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> <52797.192.54.193.37.1121788363.squirrel@rousalka.dyndns.org> Message-ID: <20050721203057.GA25485@osiris.silug.org> On Tue, Jul 19, 2005 at 05:52:43PM +0200, Nicolas Mailhot wrote: > BTW you'll get the same kind of log trashing in rawhide sa if > perl-Mail-SPF-Query is not installed, so I doubt it'll stay in extras for > long. Seems it's a core dep now. Does anything in Core depend on spamassassin? If not, maybe it would make more sense to move it to Extras? 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 mattdm at mattdm.org Thu Jul 21 20:42:33 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 21 Jul 2005 16:42:33 -0400 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050721203057.GA25485@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> <52797.192.54.193.37.1121788363.squirrel@rousalka.dyndns.org> <20050721203057.GA25485@osiris.silug.org> Message-ID: <20050721204233.GA13198@jadzia.bu.edu> On Thu, Jul 21, 2005 at 03:30:57PM -0500, Steven Pritchard wrote: > > BTW you'll get the same kind of log trashing in rawhide sa if > > perl-Mail-SPF-Query is not installed, so I doubt it'll stay in extras for > > long. Seems it's a core dep now. > Does anything in Core depend on spamassassin? If not, maybe it would > make more sense to move it to Extras? evolution. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From Nicolas.Mailhot at laPoste.net Thu Jul 21 20:47:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 21 Jul 2005 22:47:07 +0200 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050721203057.GA25485@osiris.silug.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> <52797.192.54.193.37.1121788363.squirrel@rousalka.dyndns.org> <20050721203057.GA25485@osiris.silug.org> Message-ID: <1121978827.13638.3.camel@rousalka.dyndns.org> Le jeudi 21 juillet 2005 ? 15:30 -0500, Steven Pritchard a ?crit : > On Tue, Jul 19, 2005 at 05:52:43PM +0200, Nicolas Mailhot wrote: > > BTW you'll get the same kind of log trashing in rawhide sa if > > perl-Mail-SPF-Query is not installed, so I doubt it'll stay in extras for > > long. Seems it's a core dep now. > > Does anything in Core depend on spamassassin? If not, maybe it would > make more sense to move it to Extras? I don't think sa users would appreciate. Or Red Hat, since its corporate users need spam protection too. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Thu Jul 21 20:58:07 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 21 Jul 2005 23:58:07 +0300 Subject: Repocopying? Message-ID: <1121979487.17295.12.camel@localhost.localdomain> Do we have a feature or process where when doing updates, one could request a build for let's say FC-4, and when that finishes, ask the FC-4 packages to be copied to the devel repo as-is? I'm going to update xemacs-sumo for FC-4 and devel, it's a pretty large package that could be exactly the same in both repos. It feels somewhat silly to differentiate and rebuild for both in cases like this, and of course asking builds for both using the same NEVR is out of the question, and wouldn't probably even work. From skvidal at phy.duke.edu Thu Jul 21 21:03:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 21 Jul 2005 17:03:26 -0400 Subject: Repocopying? In-Reply-To: <1121979487.17295.12.camel@localhost.localdomain> References: <1121979487.17295.12.camel@localhost.localdomain> Message-ID: <1121979806.18568.4.camel@cutter> On Thu, 2005-07-21 at 23:58 +0300, Ville Skytt? wrote: > Do we have a feature or process where when doing updates, one could > request a build for let's say FC-4, and when that finishes, ask the FC-4 > packages to be copied to the devel repo as-is? > > I'm going to update xemacs-sumo for FC-4 and devel, it's a pretty large > package that could be exactly the same in both repos. It feels somewhat > silly to differentiate and rebuild for both in cases like this, and of > course asking builds for both using the same NEVR is out of the > question, and wouldn't probably even work. > processor time is cheap - just request the second build and use a dist tag. -sv From wtogami at redhat.com Thu Jul 21 21:10:14 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Jul 2005 11:10:14 -1000 Subject: Request for approval: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1121978827.13638.3.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718175303.GA18769@osiris.silug.org> <42DCC6B3.3070909@city-fan.org> <1121786965.14525.96.camel@localhost.localdomain> <51113.192.54.193.37.1121787460.squirrel@rousalka.dyndns.org> <52797.192.54.193.37.1121788363.squirrel@rousalka.dyndns.org> <20050721203057.GA25485@osiris.silug.org> <1121978827.13638.3.camel@rousalka.dyndns.org> Message-ID: <42E00F36.9060102@redhat.com> Nicolas Mailhot wrote: > Le jeudi 21 juillet 2005 ? 15:30 -0500, Steven Pritchard a ?crit : > >>On Tue, Jul 19, 2005 at 05:52:43PM +0200, Nicolas Mailhot wrote: >> >>>BTW you'll get the same kind of log trashing in rawhide sa if >>>perl-Mail-SPF-Query is not installed, so I doubt it'll stay in extras for >>>long. Seems it's a core dep now. >> >>Does anything in Core depend on spamassassin? If not, maybe it would >>make more sense to move it to Extras? > > > I don't think sa users would appreciate. Or Red Hat, since its corporate > users need spam protection too. Well, it is a myth that RHEL is a subset of Core. RHEL is a select subset of Core + Extras. Plus I think I do a pretty good job about maintaining the FC spamassassin package. (If not, then please file Bugzilla reports.) Warren Togami wtogami at redhat.com From steve at silug.org Thu Jul 21 21:12:26 2005 From: steve at silug.org (Steven Pritchard) Date: Thu, 21 Jul 2005 16:12:26 -0500 Subject: amavisd-new again In-Reply-To: <1121722930.7652.18.camel@rousalka.dyndns.org> References: <20050718141223.GA14908@osiris.silug.org> <42DBCA0C.1060506@city-fan.org> <20050718182730.GC18769@osiris.silug.org> <1121718903.7652.3.camel@rousalka.dyndns.org> <1121719378.7652.7.camel@rousalka.dyndns.org> <1121722930.7652.18.camel@rousalka.dyndns.org> Message-ID: <20050721211226.GB25485@osiris.silug.org> If anyone wants to further pre-review it, my latest amavisd-new package is here: http://ftp.kspei.com/pub/steve/rpms/amavisd-new-2.3.2-5.src.rpm The couple of extra perl modules needed should be in the same directory. I'm almost positive all of rpmlint's complaints are bogus (or at least necessary for the way this has to interact with clamav). On Mon, Jul 18, 2005 at 11:42:10PM +0200, Nicolas Mailhot wrote: > - pid file location in conf file needs work > - same for the clamav socket location I think I fixed that. Apparently I started moving things around and then forgot what I was doing or something... :-) > - do we want to send virus notifications by default ? I would think not. > - you need to add /var/spool/amavisd/db/ to the directory list Oh? > - I don't like the default logging level of 0 :) The message it sends to the mail server gets logged, so is that really a problem? > - does the clamav conf file needs to be readable by all ? Probably not. > - do you need to create an amavisd sundir in /etc to host a single > file ? In my last package, I had the clamd config there too. So no, it doesn't. I wonder how bad it would mess up upgrades if I drop that directory... > - didn't check if you enabled quarantining, if you did you have to > provide a script that scrubs the quarantine every so often (I had chosen > to disable quarantine in my old spec) I'm pretty sure I have the quarantine disabled. (Given that nearly 50% of the mail coming through the servers I take care of is either spam or viruses, quarantining seems insane to me. As do notifications, for that matter.) > - needs some postfix integration (at least add a commented instruction > block to the postifx conf files). > The /usr/share/doc/amavisd-new-2.3.2/README_FILES/README.postfix is a > bit too much for your average user. I'll see what I can do about that. And later... > - is /var/log/amavisd/ used for anything ? No, and I can't remember why it was ever there. (This used to be a spec for amavis-ng a *long* time ago...) I dropped it. 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 ville.skytta at iki.fi Thu Jul 21 21:26:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 22 Jul 2005 00:26:00 +0300 Subject: Repocopying? In-Reply-To: <1121979806.18568.4.camel@cutter> References: <1121979487.17295.12.camel@localhost.localdomain> <1121979806.18568.4.camel@cutter> Message-ID: <1121981160.5196.9.camel@localhost.localdomain> On Thu, 2005-07-21 at 17:03 -0400, seth vidal wrote: > On Thu, 2005-07-21 at 23:58 +0300, Ville Skytt? wrote: > > Do we have a feature or process where when doing updates, one could > > request a build for let's say FC-4, and when that finishes, ask the FC-4 > > packages to be copied to the devel repo as-is? > > > > I'm going to update xemacs-sumo for FC-4 and devel, it's a pretty large > > package that could be exactly the same in both repos. It feels somewhat > > silly to differentiate and rebuild for both in cases like this, and of > > course asking builds for both using the same NEVR is out of the > > question, and wouldn't probably even work. > > > > processor time is cheap Sure, but everyone's bandwidth is not, nor is there heaps of it available everywhere. The duplicate builds gain us nothing, and do inflict completely unnecessary upgrades for end users. From wtogami at redhat.com Thu Jul 21 21:37:34 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Jul 2005 11:37:34 -1000 Subject: Repocopying? In-Reply-To: <1121981160.5196.9.camel@localhost.localdomain> References: <1121979487.17295.12.camel@localhost.localdomain> <1121979806.18568.4.camel@cutter> <1121981160.5196.9.camel@localhost.localdomain> Message-ID: <42E0159E.5030901@redhat.com> Ville Skytt? wrote: > On Thu, 2005-07-21 at 17:03 -0400, seth vidal wrote: > >>On Thu, 2005-07-21 at 23:58 +0300, Ville Skytt? wrote: >> >>>Do we have a feature or process where when doing updates, one could >>>request a build for let's say FC-4, and when that finishes, ask the FC-4 >>>packages to be copied to the devel repo as-is? >>> >>>I'm going to update xemacs-sumo for FC-4 and devel, it's a pretty large >>>package that could be exactly the same in both repos. It feels somewhat >>>silly to differentiate and rebuild for both in cases like this, and of >>>course asking builds for both using the same NEVR is out of the >>>question, and wouldn't probably even work. >>> >> >>processor time is cheap > > > Sure, but everyone's bandwidth is not, nor is there heaps of it > available everywhere. The duplicate builds gain us nothing, and do > inflict completely unnecessary upgrades for end users. > Here's one example... in FC development, builds in dist-fc4 (and dist-fc4-updates) are "inherited" by dist-fc5 during the mirror repository compose if they are not yet built in dist-fc5. This I think is good to avoid unnecessary waste of space. Warren Togami wtogami at redhat.com From taylor at haleph.com Thu Jul 21 21:56:22 2005 From: taylor at haleph.com (Taylor Stearns) Date: Thu, 21 Jul 2005 17:56:22 -0400 Subject: New package: msmtp In-Reply-To: <42D0206F.8090401@kobold.org> References: <20050622215328.GA9276@arctangent.net> <20050709172115.GA28215@arctangent.net> <42D0206F.8090401@kobold.org> Message-ID: <20050721215622.GA15280@arctangent.net> On Sat 09, Wart wrote: > Taylor Stearns wrote: > >On Wed 22, Taylor Stearns wrote: > > > >>Howdy, > >> > >>I've had some msmtp packages sitting around > >>for a while that Lee-Win Tai cleaned up and suggested submitting to > >>Extras. So here it is: > >> > >>* msmtp (GPL): > >>http://www.haleph.com/download/msmtp-1.4.1-2.src.rpm > >> > >>In the default mode, msmtp transmits a mail to an SMTP server (for example > >>at a free mail provider) which does the delivery. To use this program > >>with your mail user agent (MUA), create a configuration file with your > >>mail account(s) and tell your MUA to call msmtp instead of > >>/usr/sbin/sendmail. > > > > > >Ping. I hope somebody out there found this useful; I need CVS > >sponsorship to commit it, but I haven't heard any feedback regarding the > >package. A new version was released a few days ago which I updated the > >spec for: > > http://www.haleph.com/download/rpms/msmtp-1.4.2-1.src.rpm > > > >I would appreciate comments and/or criticism (or sponsorship). Thanks. > > Good > ---- > * Clean output from rpmlint > * Package and spec file named correctly > * md5sum matches upstream sources > * Seems to follow PackagingGuidelines > * Acceptible GPL license > * Legible spec file > * No duplicate files > * File permissions look ok > > Check > ----- > * Builds in mock for i386 and x86_64 > One build warning on both platforms. You might want to check the > upstream author to see if this is a problem: > base64.c: In function 'isbase64': > base64.c:284: warning: comparison is always true due to limited range of > data type > > Bad > --- > Use %find_lang to handle the de locale instead of > %{_prefix}/share/locale/... > > I didn't try running the program. Thanks! I addressed the locale problem and the two problems Enrico mentioned. Concerning the base64 warning from gnulib, that is apparently "harmless" (http://lists.gnu.org/archive/html/bug-gnulib/2004-11/msg00218.html) Revisions along with a new upstream version with bugfixes available at: http://www.haleph.com/download/rpms/msmtp-1.4.3-1.src.rpm Again, comments are welcome. (And I don't have CVS access) Cheers, Taylor Stearns taylor at haleph.com From tibbs at math.uh.edu Fri Jul 22 02:42:46 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 21 Jul 2005 21:42:46 -0500 Subject: Request for additional review: denyhosts In-Reply-To: <1121977159.24638.2.camel@ignacio.lan> (Ignacio Vazquez-Abrams's message of "Thu, 21 Jul 2005 16:19:19 -0400") References: <1121977159.24638.2.camel@ignacio.lan> Message-ID: >>>>> "IV" == Ignacio Vazquez-Abrams writes: IV> Who the heck puts setup.py in data_files? I'll complain upstream. IV> Anyways, the attached patch should fix this. I think I should just delete data_files altogether, as the stock config file should be %doc. - J< From jeff at ocjtech.us Fri Jul 22 02:59:11 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 21 Jul 2005 21:59:11 -0500 Subject: Repocopying? In-Reply-To: <1121981160.5196.9.camel@localhost.localdomain> References: <1121979487.17295.12.camel@localhost.localdomain> <1121979806.18568.4.camel@cutter> <1121981160.5196.9.camel@localhost.localdomain> Message-ID: <1122001151.2893.6.camel@lt16586.campus.dmacc.edu> On Fri, 2005-07-22 at 00:26 +0300, Ville Skytt? wrote: > On Thu, 2005-07-21 at 17:03 -0400, seth vidal wrote: > > On Thu, 2005-07-21 at 23:58 +0300, Ville Skytt? wrote: > > > Do we have a feature or process where when doing updates, one could > > > request a build for let's say FC-4, and when that finishes, ask the FC-4 > > > packages to be copied to the devel repo as-is? > > > > > > I'm going to update xemacs-sumo for FC-4 and devel, it's a pretty large > > > package that could be exactly the same in both repos. It feels somewhat > > > silly to differentiate and rebuild for both in cases like this, and of > > > course asking builds for both using the same NEVR is out of the > > > question, and wouldn't probably even work. > > > > > > > processor time is cheap > > Sure, but everyone's bandwidth is not, nor is there heaps of it > available everywhere. The duplicate builds gain us nothing, and do > inflict completely unnecessary upgrades for end users. Fedora Development has already diverged greatly from FC4. The most noticable divergence is probably be GTK+ 2.7 and Gnome 2.11. That means that a package built on FC4 may or may not work on a system that is tracking development. Jeff -------------- 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 symbiont at berlios.de Fri Jul 22 03:54:22 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 22 Jul 2005 11:54:22 +0800 Subject: Request for review: koffice In-Reply-To: <42DFEDBD.4080904@redhat.com> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> Message-ID: <200507221154.22370.symbiont@berlios.de> On Friday 22 July 2005 02:47, Warren Togami wrote: > If the sysadmin wants to cut it down, uninstall koffice-suite (which > effects nothinge else) and remove other sub-packages to suite tastes? That's what I was thinking. This is what I'm doing for Python-Twisted 2.x, who've split their packages and use different Versions for each sub-package. Doing so creates an upgrade path from the previous monolithic package. -- -jeff From symbiont at berlios.de Fri Jul 22 03:57:38 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 22 Jul 2005 11:57:38 +0800 Subject: Request for additional review: denyhosts In-Reply-To: <1121977159.24638.2.camel@ignacio.lan> References: <1121977159.24638.2.camel@ignacio.lan> Message-ID: <200507221157.38413.symbiont@berlios.de> On Friday 22 July 2005 04:19, Ignacio Vazquez-Abrams wrote: > Who the heck puts setup.py in data_files? Anyways, the attached patch > should fix this. Disclosure? :) This is a common "nodoc" patch that needs to be applied on a lot of python projects. It's also because of distutils brittleness in trying to coax it to place things correctly. There really should be a list for docs and lang, etc. so we can do some automatic stuff with it.. Oh well... -- -jeff From petersen at redhat.com Fri Jul 22 04:30:22 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 22 Jul 2005 13:30:22 +0900 Subject: Run of repoclosure against core-development and extras-development In-Reply-To: <604aa791050720194435c82e37@mail.gmail.com> References: <604aa791050720194435c82e37@mail.gmail.com> Message-ID: <42E0765E.2020603@redhat.com> Jeff Spaleta wrote: > package: flim - 1.14.7-3.noarch from extras-development > unresolved deps: > apel Yep, apel is being moved from Core to Extras for fc5, and is waiting to be built by the new buildsystem. Jens From ville.skytta at iki.fi Fri Jul 22 06:27:55 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 22 Jul 2005 09:27:55 +0300 Subject: Repocopying? In-Reply-To: <1122001151.2893.6.camel@lt16586.campus.dmacc.edu> References: <1121979487.17295.12.camel@localhost.localdomain> <1121979806.18568.4.camel@cutter> <1121981160.5196.9.camel@localhost.localdomain> <1122001151.2893.6.camel@lt16586.campus.dmacc.edu> Message-ID: <1122013675.5196.45.camel@localhost.localdomain> On Thu, 2005-07-21 at 21:59 -0500, Jeffrey C. Ollie wrote: > Fedora Development has already diverged greatly from FC4. The most > noticable divergence is probably be GTK+ 2.7 and Gnome 2.11. That means > that a package built on FC4 may or may not work on a system that is > tracking development. Nevertheless, there are packages that we know would just work. Such as xemacs-sumo. From andreas.bierfert at lowlatency.de Fri Jul 22 06:40:46 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 22 Jul 2005 08:40:46 +0200 Subject: Request for review: koffice In-Reply-To: <200507221154.22370.symbiont@berlios.de> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> Message-ID: <42E094EE.2020201@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Pitman wrote: > That's what I was thinking. This is what I'm doing for Python-Twisted > 2.x, who've split their packages and use different Versions for each > sub-package. Doing so creates an upgrade path from the previous > monolithic package. Just one question with this: Having a koffice-suite package which obsoletes koffice (and -i18n) and Requires all the subpackages from the new version should do the trick on update. The question is what is needed in koffice-core? Also Obsolete the old version or Conflict the old version? What is the best way to go? - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC4JTuQEQyPsWM8csRAj+aAJ9TiWAZFWqG9j0LzIEsNYiwkUkqLQCdHByl J2U+9Yl7ap33Wn2JJsexiMo= =nIwA -----END PGP SIGNATURE----- From symbiont at berlios.de Fri Jul 22 07:30:43 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 22 Jul 2005 15:30:43 +0800 Subject: Request for review: koffice In-Reply-To: <42E094EE.2020201@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> Message-ID: <200507221530.44051.symbiont@berlios.de> On Friday 22 July 2005 14:40, Andreas Bierfert wrote: > Jeff Pitman wrote: > > That's what I was thinking. This is what I'm doing for > > Python-Twisted 2.x, who've split their packages and use different > > Versions for each sub-package. Doing so creates an upgrade path > > from the previous monolithic package. > > Just one question with this: Having a koffice-suite package which > obsoletes koffice (and -i18n) and Requires all the subpackages from > the new version should do the trick on update. The question is what > is needed in koffice-core? Also Obsolete the old version or Conflict > the old version? What is the best way to go? Conflicts makes the most sense, to me. I don't know what others think. Usually you only want one package Obsoleting another. Most of this happens due to renaming of the package. -- -jeff From rc040203 at freenet.de Fri Jul 22 07:41:23 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 22 Jul 2005 09:41:23 +0200 Subject: Request for review: koffice In-Reply-To: <42E094EE.2020201@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> Message-ID: <1122018083.2015.264.camel@mccallum.corsepiu.local> On Fri, 2005-07-22 at 08:40 +0200, Andreas Bierfert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeff Pitman wrote: > > That's what I was thinking. This is what I'm doing for Python-Twisted > > 2.x, who've split their packages and use different Versions for each > > sub-package. Doing so creates an upgrade path from the previous > > monolithic package. > > > Just one question with this: Having a koffice-suite package which obsoletes > koffice (and -i18n) and Requires all the subpackages from the new version should > do the trick on update. The question is what is needed in koffice-core? Also > Obsolete the old version or Conflict the old version? What is the best way to go? Check the openoffice specs in Core. They seem to be trying to achieve the same between FC3 and FC4 versions. Ralf From wtogami at redhat.com Fri Jul 22 11:33:24 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 22 Jul 2005 01:33:24 -1000 Subject: Request for review: koffice In-Reply-To: <42E094EE.2020201@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> Message-ID: <42E0D984.4050401@redhat.com> Andreas Bierfert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeff Pitman wrote: > >>That's what I was thinking. This is what I'm doing for Python-Twisted >>2.x, who've split their packages and use different Versions for each >>sub-package. Doing so creates an upgrade path from the previous >>monolithic package. > > > > Just one question with this: Having a koffice-suite package which obsoletes > koffice (and -i18n) and Requires all the subpackages from the new version should > do the trick on update. The question is what is needed in koffice-core? Also > Obsolete the old version or Conflict the old version? What is the best way to go? I suspect neither Obsoletes nor Conflicts are needed in -core. You should test an upgrade from RH's koffice and koffice-i18n to your set of packages (including the koffice-suite which does Obsoletes those two packages) using yum in order to be sure. Warren Togami wtogami at redhat.com From rdieter at math.unl.edu Fri Jul 22 12:15:57 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Jul 2005 07:15:57 -0500 Subject: Request for review: koffice In-Reply-To: <42E0D984.4050401@redhat.com> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> <42E0D984.4050401@redhat.com> Message-ID: Warren Togami wrote: > Andreas Bierfert wrote: >> Just one question with this: Having a koffice-suite package which >> obsoletes >> koffice (and -i18n) and Requires all the subpackages from the new >> version should >> do the trick on update. The question is what is needed in >> koffice-core? Also >> Obsolete the old version or Conflict the old version? What is the best >> way to go? > > > I suspect neither Obsoletes nor Conflicts are needed in -core. IMO, -core needs a Conflicts because it really does own files that will conflict with the older koffice. -- Rex From alex at dalloz.de Fri Jul 22 12:17:34 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Fri, 22 Jul 2005 14:17:34 +0200 Subject: Request for review: keychain opt-in mechanism In-Reply-To: <1121877978.6862.174.camel@serendipity.dogma.lan> References: <1121877978.6862.174.camel@serendipity.dogma.lan> Message-ID: <1122034654.25055.103.camel@serendipity.dogma.lan> Am Mi, den 20.07.2005 schrieb Alexander Dalloz um 18:46: > http://www.uni-x.org/README.Fedora > http://www.uni-x.org/keychain.sh > http://www.uni-x.org/keychain.csh > My suggestion now should work with bash, sh, csh, tcsh and zsh. With > those I tested myself and didn't found a problem. So far I didn't test > with ksh (KornShell) available through Core. > > Alexander Unfortunately nobody replied so far and my access_log only shows one single access to keychain.sh. So I have to speak to myself and add this small comment: I meanwhile installed the FC4 ksh rpm and tested my profile scripting with a user whose shell was set to /bin/ksh - it works with that shell type too. That generally probably was to be expected, as "KornShell [...] is upward compatible with "sh" (the Bourne Shell)." (cite from ksh rpm %description). I added "ksh" in the keychain.sh in the case routine and inside the README.Fedora document. I still encourage everybody with some interest in the keychain package and small spare time to review my profile scripting proposal :) Thanks for attention. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fedora-extras-list at cygnusx-1.org Fri Jul 22 15:42:40 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 08:42:40 -0700 Subject: Core and Extras maintainers coordination Message-ID: <1122046960.10442.9.camel@ws.1sttier.net> I think coordination between core and extras maintainers needs to increase if extras isn't to be second class. Yesterday a new update for Mozilla came out, 1.7.10. Galeon in extras prevented the updates from being installed, because it hadn't been recompiled. This is just one example of how things can break when something in extras depends on a certain version of something in core. Adding a dependency checking system to the build environment that contains both core and extras packages would help detect the problems, and help coordination. Realistically you can't just automatically rebuild the dependencies in all cases. Hence some delay will have to be added if core and extras are to stay in sync at all times. Giving the extras maintainers notification and time to rebuild, or request a rebuild before an update is released. From skvidal at phy.duke.edu Fri Jul 22 15:55:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Jul 2005 11:55:23 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122046960.10442.9.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> Message-ID: <1122047723.5442.5.camel@cutter> On Fri, 2005-07-22 at 08:42 -0700, Nathan Grennan wrote: > I think coordination between core and extras maintainers needs to > increase if extras isn't to be second class. > > Yesterday a new update for Mozilla came out, 1.7.10. Galeon in extras > prevented the updates from being installed, because it hadn't been > recompiled. This is just one example of how things can break when > something in extras depends on a certain version of something in core. > > Adding a dependency checking system to the build environment that > contains both core and extras packages would help detect the problems, > and help coordination. Realistically you can't just automatically > rebuild the dependencies in all cases. Hence some delay will have to be > added if core and extras are to stay in sync at all times. Giving the > extras maintainers notification and time to rebuild, or request a > rebuild before an update is released. Anvil requested the galeon build but b/c extras buildsys is offline right now it's not built yet. -sv From gdk at redhat.com Fri Jul 22 16:10:14 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 12:10:14 -0400 (EDT) Subject: Core and Extras maintainers coordination In-Reply-To: <1122046960.10442.9.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> Message-ID: On Fri, 22 Jul 2005, Nathan Grennan wrote: > I think coordination between core and extras maintainers needs to > increase if extras isn't to be second class. I hereby banish all usage of the term "second class" to describe Fedora Extras. If you think that there are issues with Fedora Extras that need to be worked out, that's a good thing indeed. Voice them. And yes, over time, we need to improve interaction between Core and Extras -- and we will. But enough with the "second class" talk. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From fedora-extras-list at cygnusx-1.org Fri Jul 22 16:10:55 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 09:10:55 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <1122047723.5442.5.camel@cutter> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> Message-ID: <1122048655.10442.12.camel@ws.1sttier.net> On Fri, 2005-07-22 at 11:55 -0400, seth vidal wrote: > Anvil requested the galeon build but b/c extras buildsys is offline > right now it's not built yet. I already talked to him, and know he requested a rebuild. That is beside the point. The goal is to make it as transparent to the user as possible, which it has not been in this case. From rc040203 at freenet.de Fri Jul 22 16:12:41 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 22 Jul 2005 18:12:41 +0200 Subject: Core and Extras maintainers coordination In-Reply-To: <1122047723.5442.5.camel@cutter> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> Message-ID: <1122048761.2015.296.camel@mccallum.corsepiu.local> On Fri, 2005-07-22 at 11:55 -0400, seth vidal wrote: > On Fri, 2005-07-22 at 08:42 -0700, Nathan Grennan wrote: > > I think coordination between core and extras maintainers needs to > > increase if extras isn't to be second class. > > > > Yesterday a new update for Mozilla came out, 1.7.10. Galeon in extras > > prevented the updates from being installed, because it hadn't been > > recompiled. This is just one example of how things can break when > > something in extras depends on a certain version of something in core. > > > > Adding a dependency checking system to the build environment that > > contains both core and extras packages would help detect the problems, > > and help coordination. Realistically you can't just automatically > > rebuild the dependencies in all cases. Hence some delay will have to be > > added if core and extras are to stay in sync at all times. Giving the > > extras maintainers notification and time to rebuild, or request a > > rebuild before an update is released. > > Anvil requested the galeon build but b/c extras buildsys is offline > right now it's not built yet. Any ETA when it will be available again? As you can see from the note above, FE slowly is about to be facing serious problems. Ralf From skvidal at phy.duke.edu Fri Jul 22 16:18:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Jul 2005 12:18:26 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122048655.10442.12.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> Message-ID: <1122049106.5442.7.camel@cutter> On Fri, 2005-07-22 at 09:10 -0700, Nathan Grennan wrote: > On Fri, 2005-07-22 at 11:55 -0400, seth vidal wrote: > > Anvil requested the galeon build but b/c extras buildsys is offline > > right now it's not built yet. > > I already talked to him, and know he requested a rebuild. That is > beside the point. The goal is to make it as transparent to the user as > possible, which it has not been in this case. > sure, I agree it is the goal - but we don't have all the infrastructure in place to achieve such a goal right now. we're moving there but we're not there yet. So just venting spleen about it isn't going to make it happen any faster. -sv From skvidal at phy.duke.edu Fri Jul 22 16:19:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Jul 2005 12:19:32 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122048761.2015.296.camel@mccallum.corsepiu.local> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048761.2015.296.camel@mccallum.corsepiu.local> Message-ID: <1122049172.5442.9.camel@cutter> > Any ETA when it will be available again? asap. > As you can see from the note above, FE slowly is about to be facing > serious problems. problems happen. If the world comes to an end everytime problems happen then we're all screwed. -sv From gdk at redhat.com Fri Jul 22 16:19:38 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 12:19:38 -0400 (EDT) Subject: Core and Extras maintainers coordination In-Reply-To: <1122048655.10442.12.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> Message-ID: On Fri, 22 Jul 2005, Nathan Grennan wrote: > On Fri, 2005-07-22 at 11:55 -0400, seth vidal wrote: > > Anvil requested the galeon build but b/c extras buildsys is offline > > right now it's not built yet. > > I already talked to him, and know he requested a rebuild. That is > beside the point. The goal is to make it as transparent to the user as > possible, which it has not been in this case. "Adding a dependency checking system to the build environment that contains both core and extras packages would help detect the problems, and help coordination." Is this your proposed solution? --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From gdk at redhat.com Fri Jul 22 16:22:09 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 12:22:09 -0400 (EDT) Subject: Core and Extras maintainers coordination In-Reply-To: <1122048761.2015.296.camel@mccallum.corsepiu.local> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048761.2015.296.camel@mccallum.corsepiu.local> Message-ID: On Fri, 22 Jul 2005, Ralf Corsepius wrote: > As you can see from the note above, FE slowly is about to be facing > serious problems. FE has been facing serious problems since the day it was born. And yet, somehow, we limp along. So. * Spell out the problem, as you see it; * Propose a solution, if you have one. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From jamatos at fc.up.pt Fri Jul 22 16:20:47 2005 From: jamatos at fc.up.pt (=?UTF-8?B?Sm9zw6k=?= Matos) Date: Fri, 22 Jul 2005 17:20:47 +0100 Subject: Re-Request for review: pytz and python-dateutil References: <42DE7D8A.30100@cora.nwra.com> Message-ID: Orion Poplawski wrote: > Never got a review last time, trying again: > > I'm attempting to shift my python-matplotlib package to use upstream > versions of pytz and dateutil. It bundles a version of each with it, > but will not install if already present. So, it seems best to provide > official versions of pytz and python-dateutil and have python-matplotlib > require these to be present at build. > > So: > > pytz - World Timezone Definitions for Python > Author: Stuart Bishop > Introduction > > pytz brings the Olson tz database into Python. This library allows > accurate and cross platform timezone calculations using Python 2.3 or > higher. It also solves the issue of ambiguous times at the end of > daylight savings, which you can read more about in the Python Library > Reference (datetime.tzinfo). > > Amost all (over 540) of the Olson timezones are supported [*]. > > http://pytz.sourceforge.net/ > > Package at: > > http://www.cora.nwra.com/~orion/fedora/pytz.spec > http://www.cora.nwra.com/~orion/fedora/pytz-2005i-1.src.rpm I am doing a more formal review but before proceeding I noticed that you have: %install rm -rf $RPM_BUILD_ROOT %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT chmod +x $RPM_BUILD_ROOT%{python_sitelib}/pytz/*.py My problem is that you have defined the package as noarch and then you are passing -O1 to the install script, thus passing .pyo files. I don't think these goals match. :-) > python-dateutil: > > Description: > > The dateutil module provides powerful extensions to the standard > datetime module, available in Python 2.3+. > > https://moin.conectiva.com.br/DateUtil > > Package at: > > http://www.cora.nwra.com/~orion/fedora/python-dateutil.spec > http://www.cora.nwra.com/~orion/fedora/python-dateutil-0.9-1.src.rpm Notice that 1.0 is already released. Not that I think that the spec file depends on it. :-) -- Jos? Ab?lio From jamatos at fc.up.pt Fri Jul 22 16:29:33 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 22 Jul 2005 17:29:33 +0100 Subject: Core and Extras maintainers coordination In-Reply-To: <1122048655.10442.12.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> Message-ID: <200507221729.33879.jamatos@fc.up.pt> On Friday 22 July 2005 17:10, Nathan Grennan wrote: > On Fri, 2005-07-22 at 11:55 -0400, seth vidal wrote: > > Anvil requested the galeon build but b/c extras buildsys is offline > > right now it's not built yet. > > I already talked to him, and know he requested a rebuild. That is > beside the point. The goal is to make it as transparent to the user as > possible, which it has not been in this case. Notice that yesterday a new for gcc come out in testing-updates. bibtool in Core prevented the upgrades from being installed. Does this means that Core is a second upper member citi?en in Fedora? ;-) PS: Take this with a grain of salt or sugar (the one that fits best with you). -- Jos? Ab?lio From symbiont at berlios.de Fri Jul 22 16:30:11 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 23 Jul 2005 00:30:11 +0800 Subject: Core and Extras maintainers coordination In-Reply-To: <1122049172.5442.9.camel@cutter> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122048761.2015.296.camel@mccallum.corsepiu.local> <1122049172.5442.9.camel@cutter> Message-ID: <200507230030.12095.symbiont@berlios.de> On Saturday 23 July 2005 00:19, seth vidal wrote: > problems happen. If the world comes to an end everytime problems > happen then we're all screwed. Now *that* should be in fortune. Patch anyone? -- -jeff From tcallawa at redhat.com Fri Jul 22 16:31:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Jul 2005 11:31:28 -0500 Subject: Core and Extras maintainers coordination In-Reply-To: References: <1122046960.10442.9.camel@ws.1sttier.net> Message-ID: <1122049888.2511.10.camel@localhost.localdomain> On Fri, 2005-07-22 at 12:10 -0400, Greg DeKoenigsberg wrote: > On Fri, 22 Jul 2005, Nathan Grennan wrote: > > > I think coordination between core and extras maintainers needs to > > increase if extras isn't to be second class. > > I hereby banish all usage of the term "second class" to describe Fedora > Extras. Yeah. We're obviously third class. ;) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From gdk at redhat.com Fri Jul 22 16:31:45 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 12:31:45 -0400 (EDT) Subject: Core and Extras maintainers coordination In-Reply-To: <1122049888.2511.10.camel@localhost.localdomain> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122049888.2511.10.camel@localhost.localdomain> Message-ID: KHAAAAAAAAAAAAN! --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Fri, 22 Jul 2005, Tom 'spot' Callaway wrote: > On Fri, 2005-07-22 at 12:10 -0400, Greg DeKoenigsberg wrote: > > On Fri, 22 Jul 2005, Nathan Grennan wrote: > > > > > I think coordination between core and extras maintainers needs to > > > increase if extras isn't to be second class. > > > > I hereby banish all usage of the term "second class" to describe Fedora > > Extras. > > Yeah. We're obviously third class. ;) > > ~spot > -- > Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From ville.skytta at iki.fi Fri Jul 22 16:56:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 22 Jul 2005 19:56:04 +0300 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: References: <42DE7D8A.30100@cora.nwra.com> Message-ID: <1122051364.5196.58.camel@localhost.localdomain> On Fri, 2005-07-22 at 17:20 +0100, Jos? Matos wrote: > My problem is that you have defined the package as noarch and then you are > passing -O1 to the install script, thus passing .pyo files. No problem there (although explicitly generating *.pyo is no longer necessary in FC4 and later, rpmbuild does it automatically). And *.pyo are relevant both for arch-dependent and noarch packages. From fedora-extras-list at cygnusx-1.org Fri Jul 22 17:06:32 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 10:06:32 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <1122049106.5442.7.camel@cutter> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> Message-ID: <1122051992.10442.20.camel@ws.1sttier.net> On Fri, 2005-07-22 at 12:18 -0400, seth vidal wrote: > sure, I agree it is the goal - but we don't have all the infrastructure > in place to achieve such a goal right now. > > we're moving there but we're not there yet. So just venting spleen about > it isn't going to make it happen any faster. So this means that extras will be second class for the foreseeable future. Since the build up of fedora infrastructure moves out a snail's pace. Is there anything I can do to speed this up, or is this another case of having to wait for "the official people" to do it for themselves? From jamatos at fc.up.pt Fri Jul 22 17:08:18 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 22 Jul 2005 18:08:18 +0100 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <1122051364.5196.58.camel@localhost.localdomain> References: <42DE7D8A.30100@cora.nwra.com> <1122051364.5196.58.camel@localhost.localdomain> Message-ID: <200507221808.18764.jamatos@fc.up.pt> On Friday 22 July 2005 17:56, Ville Skytt? wrote: > No problem there (although explicitly generating *.pyo is no longer > necessary in FC4 and later, rpmbuild does it automatically). ?And *.pyo > are relevant both for arch-dependent and noarch packages. That is fair. I am glad to know this for other python packages I want to submit. :-) -- Jos? Ab?lio From chris at chrisgrau.com Fri Jul 22 17:12:12 2005 From: chris at chrisgrau.com (Chris Grau) Date: Fri, 22 Jul 2005 10:12:12 -0700 Subject: Request for review: keychain opt-in mechanism In-Reply-To: <1122034654.25055.103.camel@serendipity.dogma.lan> References: <1121877978.6862.174.camel@serendipity.dogma.lan> <1122034654.25055.103.camel@serendipity.dogma.lan> Message-ID: <20050722171212.GA6770@chrisgrau.com> On Fri, Jul 22, 2005 at 02:17:34PM +0200, Alexander Dalloz wrote: > Am Mi, den 20.07.2005 schrieb Alexander Dalloz um 18:46: > > > http://www.uni-x.org/README.Fedora > > > http://www.uni-x.org/keychain.sh > > http://www.uni-x.org/keychain.csh > > > My suggestion now should work with bash, sh, csh, tcsh and zsh. With > > those I tested myself and didn't found a problem. So far I didn't test > > with ksh (KornShell) available through Core. > > > > Alexander > > Unfortunately nobody replied so far and my access_log only shows one > single access to keychain.sh. So I have to speak to myself and add this > small comment: > I meanwhile installed the FC4 ksh rpm and tested my profile scripting > with a user whose shell was set to /bin/ksh - it works with that shell > type too. That generally probably was to be expected, as "KornShell > [...] is upward compatible with "sh" (the Bourne Shell)." (cite from ksh > rpm %description). I added "ksh" in the keychain.sh in the case routine > and inside the README.Fedora document. > > I still encourage everybody with some interest in the keychain package > and small spare time to review my profile scripting proposal :) > > Thanks for attention. > > Alexander I played around with your opt-in scripts a bit. They worked quite well and were very unobtrusive in an ordinary terminal. When using Gnome, keychain appears to have launched a separate ssh-agent process. This may or may not be a good thing. It would allow me to use one set of keys for my day-to-day tasks and another for cron jobs. However, I'm not sure that's the intention and I'm probably just turning a bug into a feature. In keychain.sh: - The introductory comment refers to the script as keychain.csh. - You quote the arguments to keychain on line 15. This means that if I set KCHOPTS="--nogui --quiet" in ~/.keychainrc, keychain is passed the single argument "--nogui --quiet" and doesn't know what to do with it. The same is true for SSHKEYS and GPGKEYS. - You use both "source" and "." to source files. I don't know if this was deliberate or not. I don't know if sh/bash/etc. differ in their support. It's been a while since I've coded with csh, but the script looks correct. It worked in the tests I ran with csh. In the readme file, at one point you spell Fedora as Fedore. Other than that, I didn't notice any errors and it was very informative about how I should use your scripts. Made testing easy. I noticed that, if I skip entering pass phrases for the ssh keys, keychain gives up and doesn't prompt for gpg pass phrases. That's a keychain issue, though, rather than a problem with your scripts. That's all I have for now. I hope it's helpful. I think keychain is a wonderful program. It has replaced my own script for doing more or less the same thing. I'm glad you're packaging it for Extras. -chris From rms at 1407.org Fri Jul 22 16:48:05 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 22 Jul 2005 17:48:05 +0100 Subject: ots In-Reply-To: <1121631912.2923.29.camel@roque> References: <20050717012022.60ffd702.bugs.michael@gmx.net> <1121631912.2923.29.camel@roque> Message-ID: <1122050885.14615.15.camel@roque> Almost a week off... is there any followup? Rui On Sun, 2005-07-17 at 21:25 +0100, Rui Miguel Seabra wrote: > On Sun, 2005-07-17 at 01:20 +0200, Michael Schwendt wrote: > > Package "ots" is maintained by whom? > > If nobody else, I can inherit it. > In the original ots.spec (from my cvs copy): > > %changelog > * Thu Jun 05 2003 Rui Miguel Silva Seabra > - fix spec > - disable gtk-doc (it's not building in RH 9, > maybe it's broken for some reason) > > * Fri May 02 2003 Rui Miguel Silva Seabra > - define a longer description from the README file > - explicitly set file permissions > > Rui > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -------------- 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 Fri Jul 22 17:24:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Jul 2005 12:24:53 -0500 Subject: Content guidelines update Message-ID: <1122053094.2511.18.camel@localhost.localdomain> Hi folks, I've revised the section of the PackagingGuidelines which deals with Code vs Content. Previously, Fedora Extras had a pretty big ban on Content. After careful consideration, we've changed our policy to allow certain types of Content to be included. To date, there have been very few packages submitted to FE which would fall under the old Content ban, so this should not require any changes to CVS. However, we wanted to define a better set of content guidelines to open doors for things such as font and clipart inclusion. Please take a minute or two to read the updated Content guidelines here: http://www.fedoraproject.org/wiki/PackagingGuidelines#CodeVsContent If you have any questions or concerns about the change, please feel free to ask me. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 22 17:26:40 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Jul 2005 12:26:40 -0500 Subject: ots In-Reply-To: <1122050885.14615.15.camel@roque> References: <20050717012022.60ffd702.bugs.michael@gmx.net> <1121631912.2923.29.camel@roque> <1122050885.14615.15.camel@roque> Message-ID: <1122053200.2511.21.camel@localhost.localdomain> On Fri, 2005-07-22 at 17:48 +0100, Rui Miguel Seabra wrote: > Almost a week off... is there any followup? Sure. I hereby make you the maintainer for OTS. Please make the change to owners.list in CVS. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From gdk at redhat.com Fri Jul 22 17:35:47 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 13:35:47 -0400 (EDT) Subject: Core and Extras maintainers coordination In-Reply-To: <1122051992.10442.20.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> Message-ID: On Fri, 22 Jul 2005, Nathan Grennan wrote: > > So this means that extras will be second class for the foreseeable > future. Since the build up of fedora infrastructure moves out a snail's > pace. > Since this appears to be nothing more than a deliberate attempt to annoy people, I'll let it pass. > > Is there anything I can do to speed this up, or is this another case of > having to wait for "the official people" to do it for themselves? > Speed what up, exactly? Here I return to your original note: "Adding a dependency checking system to the build environment that contains both core and extras packages would help detect the problems, and help coordination. Realistically you can't just automatically rebuild the dependencies in all cases. Hence some delay will have to be added if core and extras are to stay in sync at all times. Giving the extras maintainers notification and time to rebuild, or request a rebuild before an update is released." So what are you proposing, exactly? Are you offering to put together the depcheck code that you're alluding to here, and work with Dan and Seth to get it integrated into the build system? Or are you offering hands to help speed up the deployment of the new build system? Are you offering to set up your own plague build box? The code is in CVS -- what's stopping you? The only "official people" around here are the people who say, "I can help by doing THIS" and then stepping up and actually doing it. So you're obviously very smart. Make an offer to help, and do it in a way that doesn't sound like bitching. Or, put a sock in it. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From rc040203 at freenet.de Fri Jul 22 17:42:33 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 22 Jul 2005 19:42:33 +0200 Subject: Core and Extras maintainers coordination In-Reply-To: References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048761.2015.296.camel@mccallum.corsepiu.local> Message-ID: <1122054154.2015.311.camel@mccallum.corsepiu.local> On Fri, 2005-07-22 at 12:22 -0400, Greg DeKoenigsberg wrote: > On Fri, 22 Jul 2005, Ralf Corsepius wrote: > > > As you can see from the note above, FE slowly is about to be facing > > serious problems. > > FE has been facing serious problems since the day it was born. And yet, > somehow, we limp along. > > So. > > * Spell out the problem, as you see it; No possibility to provide updates and bug fixes, for 2 weeks. As the OP's question indicated, there exist/seem to exist dependencies between Core and Extras which require/could require rebuilding packages at Extras. Not worth mentioning not being able to provide potential (I am not aware of any) security fixes. > * Propose a solution, if you have one. You'd have to ask Seth. I am quite surprised to having seen him announcing a downtime for a weekend, but the system not having come up again since then. I would have expected the "buildsystem" having undergone sufficient testing to provide a "nearly smooth" transition, before somebody would want to make such an announcement. Now, I'd propose to set Seth and Dan (and who else might be involved) a deadline (E.g. Monday morning). If they can bring the system up in reasonable fashion, fine, I'll be amongst the first to congratulate, then. If not, I would propose to back up to the old "buildsystem" and to give them more time to bring up the new buildsystem without being unnecessarily pressured. Ralf From bugs.michael at gmx.net Fri Jul 22 17:55:17 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jul 2005 19:55:17 +0200 Subject: Core and Extras maintainers coordination In-Reply-To: References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048761.2015.296.camel@mccallum.corsepiu.local> Message-ID: <20050722195517.5efd94bf.bugs.michael@gmx.net> On Fri, 22 Jul 2005 12:22:09 -0400 (EDT), Greg DeKoenigsberg wrote: > > On Fri, 22 Jul 2005, Ralf Corsepius wrote: > > > As you can see from the note above, FE slowly is about to be facing > > serious problems. > > FE has been facing serious problems since the day it was born. And yet, > somehow, we limp along. > > So. > > * Spell out the problem, as you see it; > * Propose a solution, if you have one. Keeping a backup build system (mind you, Seth had a working one) would have been a very good idea. Particularly with regard to security fixes or other important updates. From gdk at redhat.com Fri Jul 22 18:01:15 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 14:01:15 -0400 (EDT) Subject: Core and Extras maintainers coordination In-Reply-To: <1122054154.2015.311.camel@mccallum.corsepiu.local> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048761.2015.296.camel@mccallum.corsepiu.local> <1122054154.2015.311.camel@mccallum.corsepiu.local> Message-ID: On Fri, 22 Jul 2005, Ralf Corsepius wrote: > > * Spell out the problem, as you see it; > No possibility to provide updates and bug fixes, for 2 weeks. > > > * Propose a solution, if you have one. > Now, I'd propose to set Seth and Dan (and who else might be involved) a > deadline (E.g. Monday morning). If they can bring the system up in > reasonable fashion, fine, I'll be amongst the first to congratulate, > then. > > If not, I would propose to back up to the old "buildsystem" and to give > them more time to bring up the new buildsystem without being > unnecessarily pressured. Well put and fair enough. And to add Michael Schwendt's take: "Keeping a backup build system (mind you, Seth had a working one) would have been a very good idea. Particularly with regard to security fixes or other important updates." For a long time, we weren't getting any builds out the door at all, except by Seth's manual cranking. And then we put an automated build system in place, and what do you know, it worked decently enough, and people came to rely upon it. As far as the deadline proposal: I think we're probably in a position (and Seth, correct me if I'm wrong) in which we're quite close, and reverting to the old build system will be harder than finishing the new build system. So for now, we probably just need to push on as fast as we can, and take our lumps in the process. But the new build system will, fortunately, be a vast improvement. Lesson learned for the future: people have already come to rely upon the build system, and we need to figure out how to treat it like the critical piece of infrastructure that it is. But it's still better than building every package by hand, which is where we were 3 months ago. If that's too slow, sorry -- but that's the way it is. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From jspaleta at gmail.com Fri Jul 22 18:03:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 22 Jul 2005 14:03:01 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> Message-ID: <604aa79105072211035ba5886@mail.gmail.com> On 7/22/05, Greg DeKoenigsberg wrote: > So what are you proposing, exactly? Are you offering to put together the > depcheck code that you're alluding to here, and work with Dan and Seth to > get it integrated into the build system? Could the dep-reporting code being used for the daily rawhide reports be extended to include Extras as well? My understanding is that its a variation on what repomanage does and run across multiple arches. In another thread, I talked about my experience running repomanage against core-development and extras-development on x86 and the idea of generating something like a weekly depbreakage report. If Panu can hack repomanage to only check the deps for the "newest" packages in a repo that solves one of the biggest problems remaining that I can see to using repomanage as a depbreakage reporting tool for Core+Updates+Extras. -jef From gdk at redhat.com Fri Jul 22 18:30:11 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 22 Jul 2005 14:30:11 -0400 (EDT) Subject: Build system info In-Reply-To: <604aa79105072211035ba5886@mail.gmail.com> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <604aa79105072211035ba5886@mail.gmail.com> Message-ID: For those who are actually interested in what's going on in newbuildsystemland, there is a page on the wiki that's quite informative: http://fedoraproject.org/wiki/Extras/BuildSystem --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From qspencer at ieee.org Fri Jul 22 18:45:39 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 22 Jul 2005 13:45:39 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42DE7D39.4070000@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> Message-ID: <42E13ED3.5090405@ieee.org> Orion Poplawski wrote: > Orion Poplawski wrote: > >> This is my first attempt at packaging a kde app, so there are surely >> some issues. In particular, I don?t seem to get an icon in my KDE >> menu, so I must not be installing icons is the right place or the >> .desktop file must not be right. >> >> Description: >> >> Kompos? offers a great new way to manage a big number of windows on >> different Virtual Desktops. It creates a fullscreen view where every >> window is represented by a scaled screenshot of its own. >> Thanks to the KDE framework it is possible to create those >> screenshots "on the fly" while you are working without much overhead. >> The image scaling is done through the high performance image library >> Imlib2. >> >> Since version 0.5 support for the Composite and Damage extensions has >> been added, which allows us to display window contents without >> grabbing screenshots. However with the current state of graphics >> drivers XOrg may be awfully slow (or even crash sometimes) when >> enabling the Composite extension. >> So blame me for your bad gfx drivers :) >> >> URL http://kompose.berlios.de/ >> >> Package: >> http://www.cora.nwra.com/~orion/fedora/kompose.spec >> http://www.cora.nwra.com/~orion/fedora/kompose-0.5.2-0.beta1.src.rpm >> > > Never got any takers, can someone please review? > OK, I'm not much of an expert on the menu stuff you mentioned, but here are some other issues I found: 1. Release: 0.beta1%{?fcdist} Did you mean %{?dist} ? 2. CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure --disable-rpath If this is a KDE app, I assume it's all in C++, right? So is the CFLAGS necessary? Also, I'm not sure the flags actually do anything if you use %configure -- I think you may want to use ./configure instead. 3. Trying to build on an up-to-date FC4 system, I got the following configure error: checking for Qt... configure: error: Qt (>= Qt 3.0) (headers and libraries) not found. Please check your installation! I really don't understand this because "rpm -q qt qt-devel" gives: qt-3.3.4-15.1 qt-devel-3.3.4-15.1 -Quentin From alex at dalloz.de Fri Jul 22 18:48:15 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Fri, 22 Jul 2005 20:48:15 +0200 Subject: Request for review: keychain opt-in mechanism In-Reply-To: <20050722171212.GA6770@chrisgrau.com> References: <1121877978.6862.174.camel@serendipity.dogma.lan> <1122034654.25055.103.camel@serendipity.dogma.lan> <20050722171212.GA6770@chrisgrau.com> Message-ID: <1122058094.25055.190.camel@serendipity.dogma.lan> Am Fr, den 22.07.2005 schrieb Chris Grau um 19:12: Chris, thank you much for taking the time and writing this helpful feedback message! > I played around with your opt-in scripts a bit. They worked quite well > and were very unobtrusive in an ordinary terminal. When using Gnome, > keychain appears to have launched a separate ssh-agent process. This > may or may not be a good thing. It would allow me to use one set of > keys for my day-to-day tasks and another for cron jobs. However, I'm > not sure that's the intention and I'm probably just turning a bug into a > feature. There should be only 1 ssh-agent process per user: if an ssh-agent is already running keychain will only add keys to that one based on it's call; if none is running for the user keychain starts an ssh-agent. That is at least what the documentation says and how I observe it here on my workstation. I got another reply, Ralf Corsepius wrote me personally and said, if the keychain.sh would be stripped down to pure "sh" (bourne shell) syntax the script could be made simply by omitting the differing between bash, zsh, sh and ksh. That is true and to remove the "case" selection in the keychain.csh script would be possible too. If focus should be to have the most easy script solution, then I will follow that suggestion. My script proposals differ between shells by using "case" to be in a way close to the keychain(1) manpage. I am open for votings. > In keychain.sh: > - The introductory comment refers to the script as keychain.csh. Corrected. A copy mistake. > - You quote the arguments to keychain on line 15. This means that if > I set KCHOPTS="--nogui --quiet" in ~/.keychainrc, keychain is passed > the single argument "--nogui --quiet" and doesn't know what to do > with it. The same is true for SSHKEYS and GPGKEYS. Doh! That is of course a bad mistake - corrected as well. > - You use both "source" and "." to source files. I don't know if this > was deliberate or not. I don't know if sh/bash/etc. differ in their > support. I am neither the shell god I should have to be to answer that question without any doubt. At least I would say that "." is more basic so that the Bourne Shell (sh) knows that, while "source" is what the Bourne-again Shell (bash) offers. The bash is though capable of the "." syntax. To be frank, I followed the examples "man 1 keychain" contains for the different shells. > It's been a while since I've coded with csh, but the script looks > correct. It worked in the tests I ran with csh. Fine. > In the readme file, at one point you spell Fedora as Fedore. Other than > that, I didn't notice any errors and it was very informative about how I > should use your scripts. Made testing easy. Corrected that typo. You had a close reading, thanks :) > I noticed that, if I skip entering pass phrases for the ssh keys, > keychain gives up and doesn't prompt for gpg pass phrases. That's a > keychain issue, though, rather than a problem with your scripts. I have no gpg-agent (gnupg2) on my old FC2. If I abort one SSH key I am still asked for password entry for another one. I would expect that behaviour too for GPG keys. After testing my own later I am willing to mail the keychain author. > That's all I have for now. I hope it's helpful. I think keychain is a > wonderful program. It has replaced my own script for doing more or less > the same thing. I'm glad you're packaging it for Extras. Absolutely helpful. And I am glad that once keychain is in Extras it has a fan :) > -chris My invitation is still there for especially Chip Turner to comment on my scripting style, and Paul Howarth too, whether things are simple enough now - with respect to what Ralf answered me for simplifying the profile scripts by not distinguishing between shell types inside keychain.{sh,csh}. Bourne Shell types and C Shell types must be differed anyway. Ville Skytt? may have a good advise too. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fedora-extras-list at cygnusx-1.org Fri Jul 22 18:54:32 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 11:54:32 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> Message-ID: <1122058472.10442.56.camel@ws.1sttier.net> On Fri, 2005-07-22 at 13:35 -0400, Greg DeKoenigsberg wrote: > Speed what up, exactly? Here I return to your original note: > > "Adding a dependency checking system to the build environment that > contains both core and extras packages would help detect the problems, and > help coordination. Realistically you can't just automatically rebuild the > dependencies in all cases. Hence some delay will have to be added if core > and extras are to stay in sync at all times. Giving the extras maintainers > notification and time to rebuild, or request a rebuild before an update is > released." > > So what are you proposing, exactly? Are you offering to put together the > depcheck code that you're alluding to here, and work with Dan and Seth to > get it integrated into the build system? Overall I am offering to do whatever I can, but I don't know the build system inside out. If someone could provide a list of what they think it would take, then I could review it to say what I would be able to do. But below is my best guess based on what I do know. My understanding is that core and extras are two separate build systems. I see the need for this to be built into both. It looks like repoquery in yum-utils can do a good part of it. If the build box had yum installed in a standard way then a "repoquery --whatrequires package-that-was-just-rebuilt" would give them a list of packages to review. The trickier part is finding the maintainer information. This can be found via the changelog, but there can be multiple maintainers and hence it can be unclear who you should talk to. The command "rpm -q --changelog package | grep '^\*' | cut -f2 -d\< | cut -f1 -d\> | sort | uniq" Will give you a list of everyone in the changelog who you could notify. You could notify everyone, but that assumes that they are all still working on it. On the flip side, if you only talk to one, it might be the wrong one. The best way would be to have a set maintainer in the rpm. Packager seems like a good place, but instead of listing the maintainer, on Core packages it says Red Hat. The extras packages I looked at don't mention a Packager. Hence it seems a new field called Maintainer might be in order, as the right person to talk to about conflicts. Then maybe something like repoquery could be used to get both the package names and their maintainers. This could be called automatically at the end of the build scripts. From wart at kobold.org Fri Jul 22 18:54:45 2005 From: wart at kobold.org (Michael Thomas) Date: Fri, 22 Jul 2005 11:54:45 -0700 Subject: Request for review: tcllib In-Reply-To: <42D87065.7070703@redhat.com> References: <42CEC83A.9090100@kobold.org> <20050716011052.63ee6296.bugs.michael@gmx.net> <42D87065.7070703@redhat.com> Message-ID: <42E140F5.4000301@kobold.org> Jens Petersen wrote: > Michael Schwendt wrote: > >>On Fri, 08 Jul 2005 11:38:50 -0700, Michael Thomas wrote: >> >> >>>I just discovered that tcllib-1.3 was in FC1 but later removed. I've >>>imported tcllib -1.7 into CVS and now need a review: > > > Right: sorry I meant to follow up earlier... > > >>But where does tcllib come from? It's not in the FC1 package list. It >>doesn't list a Red Hat engineer in the spec changelog. It looks like it >>might come from the fedora.us QA queue, as it's not in the list of >>released fedora.us packages either. > > > tcllib was part of the jumbo tcltk package until FC1. > When tcltk was split up into separate source packages > tcllib was dropped from Core. Later a few people requested > it back, but it was suggested that it should into Extras. > And here we are. :-) The tcllib rpm originally came from here: http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/Fedora/RPMS/tcllib-1.3-93.i386.rpm The RPM that I generated was not based on the FC1 package, but on an updated package written by Jean-Luc Fontaine. I thought I needed to get an explicit APPROVE before I could request a build. If that's not the case then I'll go ahead and update owners.list, request a FC4 branch, and then request builds for both FC4 and devel. --Mike From paul at city-fan.org Fri Jul 22 19:07:27 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 22 Jul 2005 20:07:27 +0100 Subject: Core and Extras maintainers coordination In-Reply-To: <1122058472.10442.56.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> Message-ID: <1122059247.3263.58.camel@laurel.intra.city-fan.org> On Fri, 2005-07-22 at 11:54 -0700, Nathan Grennan wrote: > The best way would be to have a set maintainer in the rpm. Packager > seems like a good place, but instead of listing the maintainer, on Core > packages it says Red Hat. The extras packages I looked at don't mention > a Packager. Hence it seems a new field called Maintainer might be in > order, as the right person to talk to about conflicts. There's no need for this; the owners.list file in the "owners" module of Extras cvs contains the contact address for the current maintainer of each package. awk -F\| '$2 == "packagename" { print $4 }' owners.list Paul. -- Paul Howarth From fedora-extras-list at cygnusx-1.org Fri Jul 22 19:14:11 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 12:14:11 -0700 Subject: Content guidelines update In-Reply-To: <1122053094.2511.18.camel@localhost.localdomain> References: <1122053094.2511.18.camel@localhost.localdomain> Message-ID: <1122059651.10442.63.camel@ws.1sttier.net> On Fri, 2005-07-22 at 12:24 -0500, Tom 'spot' Callaway wrote: > Hi folks, > > I've revised the section of the PackagingGuidelines which deals with > Code vs Content. > > Previously, Fedora Extras had a pretty big ban on Content. After careful > consideration, we've changed our policy to allow certain types of > Content to be included. > > To date, there have been very few packages submitted to FE which would > fall under the old Content ban, so this should not require any changes > to CVS. However, we wanted to define a better set of content guidelines > to open doors for things such as font and clipart inclusion. > > Please take a minute or two to read the updated Content guidelines here: > http://www.fedoraproject.org/wiki/PackagingGuidelines#CodeVsContent > > If you have any questions or concerns about the change, please feel free > to ask me. >From the bottom of the page of the url above: Some examples of content which are not permissable: Ogg/mp3 files ^^^ Huh? The distribution supports Ogg and already includes Ogg files. Here is a short list of some of the Ogg files in my /usr/share/sounds directory: KDE_Beep.ogg KDE_Beep_Car.ogg KDE_Beep_Classic.ogg KDE_Beep_Connect.ogg KDE_Beep_Digital_1.ogg KDE_Beep_Digital_2.ogg KDE_Beep_Double.ogg KDE_Beep_Harsh.ogg KDE_Beep_Phone_1.ogg KDE_Beep_Phone_2.ogg KDE_Bottles.ogg rpm -qf KDE_Beep.ogg kdebase-3.4.1-0.fc4.1 I see others in /usr/share/apps, and there are probably others in packages I don't have installed. From jamatos at fc.up.pt Fri Jul 22 19:15:12 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 22 Jul 2005 20:15:12 +0100 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: References: <42DE7D8A.30100@cora.nwra.com> Message-ID: <200507222015.12998.jamatos@fc.up.pt> On Friday 22 July 2005 17:20, Jos? Matos wrote: > Orion Poplawski wrote: > > > > http://pytz.sourceforge.net/ > > > > Package at: > > > > http://www.cora.nwra.com/~orion/fedora/pytz.spec > > http://www.cora.nwra.com/~orion/fedora/pytz-2005i-1.src.rpm This are my first reviews of Fedora Extras packages I hope I have checked all the requirements for a review. GOOD: - Package builds in mock. - rpmlint: invalid-license MIT License This is minor, rpmlint expects MIT. Probably it is the right fix, there is no need to have License as prefix and suffix. :-) - MIT is the license of the package and is a valid license for Fedora. - The license text is included in the package. - Package Naming Guidelines: it is a python package and its name starts with py. - Spec file name: The spec file name must matches the base package name. - The spec file is readable and is written in American English. - BuildRequires: correct. - No locales and no shared libraries. - The package owns all directories that it creates. - %clean section is present and is correct. - Macros are used consistently. - The package contains code (it could as well be considered content ;-). - %doc is accordingly to the packaging rules. - There are no devel files as well as static or dynamic libraries. - md5sum for source is the same as upstreams. MINOR: - Is it really necessary to include PKG-INFO into docs? Isn't it redundant? - Is it really necessary to make all python files executable? I don't see this rule anywhere... If the last item is supported by any more experienced packager then consider this as approved. > > python-dateutil: > > > > Description: > > > > The dateutil module provides powerful extensions to the standard > > datetime module, available in Python 2.3+. > > > > https://moin.conectiva.com.br/DateUtil > > > > Package at: > > > > http://www.cora.nwra.com/~orion/fedora/python-dateutil.spec > > http://www.cora.nwra.com/~orion/fedora/python-dateutil-0.9-1.src.rpm GOOD: - Package builds in mock. - rpmlint: no warnings. - the license text is included in the package and is a valid license for Fedora. - Package Naming Guidelines: it is a python package and its name starts with python. - Spec file name: The spec file name must matches the base package name. - The spec file is readable and is written in American English. - BuildRequires: correct. - No locales and no shared libraries. - The package owns all directories that it creates. - %clean section is present and is correct. - Macros are used consistently. - The package contains code. - %doc is accordingly to the packaging rules. - There are no devel files as well as static or dynamic libraries. - md5sum for source is the same as upstreams (I have checked using a local copy, as since this package was submitted for approval there was another release upstreams and the older release does not seems to easily accessible from outside) MINOR: - Is it really necessary to include PKG-INFO into docs? Isn't it redundant? The last point is really minor so consider this package approved. -- Jos? Ab?lio From fedora-extras-list at cygnusx-1.org Fri Jul 22 19:16:08 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 12:16:08 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <1122059247.3263.58.camel@laurel.intra.city-fan.org> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> Message-ID: <1122059768.10442.66.camel@ws.1sttier.net> On Fri, 2005-07-22 at 20:07 +0100, Paul Howarth wrote: > There's no need for this; the owners.list file in the "owners" module of > Extras cvs contains the contact address for the current maintainer of > each package. > > awk -F\| '$2 == "packagename" { print $4 }' owners.list Cool, though I would still prefer to see this added to the rpm. Regular users might want this information and having to dig it out of cvs isn't good. From bugs.michael at gmx.net Fri Jul 22 19:32:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jul 2005 21:32:31 +0200 Subject: Re-Request for review: kompose In-Reply-To: <42E13ED3.5090405@ieee.org> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> Message-ID: <20050722213231.21497185.bugs.michael@gmx.net> On Fri, 22 Jul 2005 13:45:39 -0500, Quentin Spencer wrote: > 2. CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure > --disable-rpath > If this is a KDE app, I assume it's all in C++, right? So is the CFLAGS > necessary? Also, I'm not sure the flags actually do anything if you use > %configure -- I think you may want to use ./configure instead. No. Use %configure --disable-rpath Contrary to ./configure, the %configure macro sets CFLAGS, CXXFLAGS and FLAGS properly. > 3. Trying to build on an up-to-date FC4 system, I got the following > configure error: > checking for Qt... configure: error: Qt (>= Qt 3.0) (headers and > libraries) not found. Please check your installation! > I really don't understand this because "rpm -q qt qt-devel" gives: > qt-3.3.4-15.1 > qt-devel-3.3.4-15.1 QTDIR environment variable not set. Take a look at other packages on how to do it, e.g. "konversation". From tcallawa at redhat.com Fri Jul 22 19:32:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Jul 2005 14:32:19 -0500 Subject: Content guidelines update In-Reply-To: <1122059651.10442.63.camel@ws.1sttier.net> References: <1122053094.2511.18.camel@localhost.localdomain> <1122059651.10442.63.camel@ws.1sttier.net> Message-ID: <1122060739.2511.56.camel@localhost.localdomain> On Fri, 2005-07-22 at 12:14 -0700, Nathan Grennan wrote: > Some examples of content which are not permissable: > > Ogg/mp3 files > ^^^ Sound files which are included as part of a software package or a theme, that serve a purpose to that package or theme, are fine. I'm more saying that you can't include Van Halen's greatest hits, even if Van Halen gives you permission to freely distribute them. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jspaleta at gmail.com Fri Jul 22 19:32:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 22 Jul 2005 15:32:27 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122059768.10442.66.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> Message-ID: <604aa79105072212325b5e0173@mail.gmail.com> On 7/22/05, Nathan Grennan wrote: > Cool, though I would still prefer to see this added to the rpm. > Regular users might want this information and having to dig it out of > cvs isn't good. why do normal users need this? Packages can have a team of maintainers... why can't issues just go into bugzilla where all the people who are working to maintain specific packages can be informed? Why do you need an explicit name of a person as a regular user? -jef From dennis at ausil.us Fri Jul 22 19:40:54 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 22 Jul 2005 14:40:54 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42E13ED3.5090405@ieee.org> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> Message-ID: <200507221440.55921.dennis@ausil.us> Once upon a time Friday 22 July 2005 1:45 pm, Quentin Spencer wrote: > Orion Poplawski wrote: > > Orion Poplawski wrote: > >> This is my first attempt at packaging a kde app, so there are surely > >> some issues. In particular, I don?t seem to get an icon in my KDE > >> menu, so I must not be installing icons is the right place or the > >> .desktop file must not be right. > >> > >> Description: > >> > >> Kompos? offers a great new way to manage a big number of windows on > >> different Virtual Desktops. It creates a fullscreen view where every > >> window is represented by a scaled screenshot of its own. > >> Thanks to the KDE framework it is possible to create those > >> screenshots "on the fly" while you are working without much overhead. > >> The image scaling is done through the high performance image library > >> Imlib2. > >> > >> Since version 0.5 support for the Composite and Damage extensions has > >> been added, which allows us to display window contents without > >> grabbing screenshots. However with the current state of graphics > >> drivers XOrg may be awfully slow (or even crash sometimes) when > >> enabling the Composite extension. > >> So blame me for your bad gfx drivers :) > >> > >> URL http://kompose.berlios.de/ > >> > >> Package: > >> http://www.cora.nwra.com/~orion/fedora/kompose.spec > >> http://www.cora.nwra.com/~orion/fedora/kompose-0.5.2-0.beta1.src.rpm > > > > Never got any takers, can someone please review? > > OK, I'm not much of an expert on the menu stuff you mentioned, but here > are some other issues I found: > > 1. Release: 0.beta1%{?fcdist} > Did you mean %{?dist} ? > > 2. CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure > --disable-rpath > If this is a KDE app, I assume it's all in C++, right? So is the CFLAGS > necessary? Also, I'm not sure the flags actually do anything if you use > %configure -- I think you may want to use ./configure instead. > i would change CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure --disable-rpath make to unset QTDIR || : ; . /etc/profile.d/qt.sh export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include %configure make %{?_smp_mflags} use desktop-file-install to install your .desktop file. I dont think your patch to the .desktop file is needed. make sure you add --vendor=fedora --add-category=X-Fedora --delete-original I have used the following script from Rex Deiter in the %install section to catch all the language stuff ## File lists # locale's %find_lang %{name} || touch %{name}.lang # HTML HTML_DIR=$(kde-config --expandvars --install html) if [ -d $RPM_BUILD_ROOT$HTML_DIR ]; then for lang_dir in $RPM_BUILD_ROOT$HTML_DIR/* ; do lang=$(basename $lang_dir) echo "%lang($lang) %doc $HTML_DIR/$lang/*" >> %{name}.lang done fi and then use %files -f %{name}.lang instead of %files to pick up all the language files kompose doesnt own /usr/share/apps/kompose/ I will look at it some more later tonight dennis From ville.skytta at iki.fi Fri Jul 22 19:44:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 22 Jul 2005 22:44:00 +0300 Subject: Core and Extras maintainers coordination In-Reply-To: <1122059768.10442.66.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> Message-ID: <1122061440.5196.70.camel@localhost.localdomain> On Fri, 2005-07-22 at 12:16 -0700, Nathan Grennan wrote: > On Fri, 2005-07-22 at 20:07 +0100, Paul Howarth wrote: > > There's no need for this; the owners.list file in the "owners" module of > > Extras cvs contains the contact address for the current maintainer of > > each package. > > > > awk -F\| '$2 == "packagename" { print $4 }' owners.list > > Cool, though I would still prefer to see this added to the rpm. > Regular users might want this information and having to dig it out of > cvs isn't good. There's also the CVS web interface: http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&rev=.&view=auto And just to point out, depending on the use case, there are already several sources for that for regular users, in more human friendly format than the above: If one just wants to know the name of the maintainer: https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras If one wants to report a bug or suggest enhancements etc, use Bugzilla. If one wants to know who has been working on the package lately, there's the package changelog. From orion at cora.nwra.com Fri Jul 22 20:24:33 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 14:24:33 -0600 Subject: Re-Request for review: kompose In-Reply-To: <200507221440.55921.dennis@ausil.us> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <200507221440.55921.dennis@ausil.us> Message-ID: <42E15601.9000403@cora.nwra.com> Dennis Gilmore wrote: > > i would change > > CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure --disable-rpath > make > > to > > unset QTDIR || : ; . /etc/profile.d/qt.sh > export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include > %configure > make %{?_smp_mflags} > Done. Thanks for the QT stuff. > use desktop-file-install to install your .desktop file. I dont think your > patch to the .desktop file is needed. make sure you add --vendor=fedora > --add-category=X-Fedora --delete-original I think I've got this right: %install %makeinstall desktop-file-install --vendor=fedora --add-category=X-Fedora \ --delete-original --dir %{buildroot}%{_datadir}/applications \ src/kompose.desktop rm $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop > I have used the following script from Rex Deiter in the %install section to > catch all the language stuff > > ## File lists > # locale's > %find_lang %{name} || touch %{name}.lang > # HTML > HTML_DIR=$(kde-config --expandvars --install html) > if [ -d $RPM_BUILD_ROOT$HTML_DIR ]; then > for lang_dir in $RPM_BUILD_ROOT$HTML_DIR/* ; do > lang=$(basename $lang_dir) > echo "%lang($lang) %doc $HTML_DIR/$lang/*" >> %{name}.lang > done > fi > > and then use %files -f %{name}.lang instead of %files to pick up all the > language files > Thanks! > kompose doesnt own /usr/share/apps/kompose/ Changed %files to just list %{_datadir}/apps/kompose/ 0.5.3 just came out. So, new stuff at: http://www.cora.nwra.com/~orion/fedora/kompose-0.5.3-1.src.rpm http://www.cora.nwra.com/~orion/fedora/kompose.spec - Orion From orion at cora.nwra.com Fri Jul 22 20:26:19 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 14:26:19 -0600 Subject: Re-Request for review: kompose In-Reply-To: <20050722213231.21497185.bugs.michael@gmx.net> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <20050722213231.21497185.bugs.michael@gmx.net> Message-ID: <42E1566B.7080001@cora.nwra.com> Michael Schwendt wrote: > > No. Use %configure --disable-rpath > Contrary to ./configure, the %configure macro sets CFLAGS, CXXFLAGS > and FLAGS properly. looks like %configure sets --disable-rpath. From smooge at gmail.com Fri Jul 22 20:28:46 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 22 Jul 2005 14:28:46 -0600 Subject: clamd handicraft work In-Reply-To: <20050630100524.1a45b781@localhost.localdomain> References: <20050630100524.1a45b781@localhost.localdomain> Message-ID: <80d7e4090507221328765686f8@mail.gmail.com> On 6/30/05, Kai Raven wrote: > Hi, > > i have installed clamav & clamd successfully under FC4 from Extras but i don't > like the whole procedure the user must execute as mentioned in the Readme > Going over items from the list, I think that two things that would be useful to add would be a system-clamav-config [which would basically ask when you want to run the clam updates and put that in the crontab.]. Would it be useful to put something in the crontab that randomizes the time of the update like this untested syntax? 0 0 * * * perl -le 'sleep rand 14400;' && {/usr/bin/freshclam --quiet && { test -x /usr/sbin/clamav-notify-servers && exec /usr/sbin/clamav-notify-servers || :; }} -- Stephen J Smoogen. CSIRT/Linux System Administrator From bugs.michael at gmx.net Fri Jul 22 20:42:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jul 2005 22:42:25 +0200 Subject: Re-Request for review: kompose In-Reply-To: <42E1566B.7080001@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <20050722213231.21497185.bugs.michael@gmx.net> <42E1566B.7080001@cora.nwra.com> Message-ID: <20050722224225.2573fa22.bugs.michael@gmx.net> On Fri, 22 Jul 2005 14:26:19 -0600, Orion Poplawski wrote: > Michael Schwendt wrote: > > > > No. Use %configure --disable-rpath > > Contrary to ./configure, the %configure macro sets CFLAGS, CXXFLAGS > > and FLAGS properly. > > looks like %configure sets --disable-rpath. It doesn't do that on FC3. Compare with output of rpm --eval %configure From orion at cora.nwra.com Fri Jul 22 20:43:25 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 14:43:25 -0600 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <1122051364.5196.58.camel@localhost.localdomain> References: <42DE7D8A.30100@cora.nwra.com> <1122051364.5196.58.camel@localhost.localdomain> Message-ID: <42E15A6D.5040500@cora.nwra.com> Ville Skytt? wrote: > On Fri, 2005-07-22 at 17:20 +0100, Jos? Matos wrote: > > >> My problem is that you have defined the package as noarch and then you are >>passing -O1 to the install script, thus passing .pyo files. > > > No problem there (although explicitly generating *.pyo is no longer > necessary in FC4 and later, rpmbuild does it automatically). And *.pyo > are relevant both for arch-dependent and noarch packages. > Being very much a python newbie, I don't know about -O1 and .pyo files. I do see that if I remove the -O1 I don't see any .pyo files in my rpm (on FC4). I'll leave it off I guess. From qspencer at ieee.org Fri Jul 22 20:46:49 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 22 Jul 2005 15:46:49 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42E15601.9000403@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <200507221440.55921.dennis@ausil.us> <42E15601.9000403@cora.nwra.com> Message-ID: <42E15B39.1040106@ieee.org> Orion Poplawski wrote: > Dennis Gilmore wrote: > >> >> i would change >> >> CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure >> --disable-rpath >> make >> >> to >> unset QTDIR || : ; . /etc/profile.d/qt.sh >> export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include >> %configure >> make %{?_smp_mflags} >> > > Done. Thanks for the QT stuff. > >> use desktop-file-install to install your .desktop file. I dont >> think your patch to the .desktop file is needed. make sure you add >> --vendor=fedora --add-category=X-Fedora --delete-original > > > I think I've got this right: > > %install > %makeinstall > desktop-file-install --vendor=fedora --add-category=X-Fedora \ > --delete-original --dir %{buildroot}%{_datadir}/applications \ > src/kompose.desktop > rm $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop > >> I have used the following script from Rex Deiter in the %install >> section to catch all the language stuff >> >> ## File lists >> # locale's >> %find_lang %{name} || touch %{name}.lang >> # HTML >> HTML_DIR=$(kde-config --expandvars --install html) >> if [ -d $RPM_BUILD_ROOT$HTML_DIR ]; then >> for lang_dir in $RPM_BUILD_ROOT$HTML_DIR/* ; do >> lang=$(basename $lang_dir) >> echo "%lang($lang) %doc $HTML_DIR/$lang/*" >> %{name}.lang >> done >> fi >> >> and then use %files -f %{name}.lang instead of %files to pick up >> all the language files >> > > Thanks! > >> kompose doesnt own /usr/share/apps/kompose/ > > > Changed %files to just list %{_datadir}/apps/kompose/ > > 0.5.3 just came out. So, new stuff at: > > http://www.cora.nwra.com/~orion/fedora/kompose-0.5.3-1.src.rpm > http://www.cora.nwra.com/~orion/fedora/kompose.spec > > - Orion Much better. It builds, installs, and uninstalls fine now. Running rpmlint now returns the following warnings: W: kompose dangling-symlink /usr/share/doc/HTML/en/kompose/common /usr/share/doc/HTML/en/common W: kompose symlink-should-be-relative /usr/share/doc/HTML/en/kompose/common /usr/share/doc/HTML/en/common I don't have time to look at these more carefully right now, but I thought I'd at least report that they exist. -Quentin From fedora-extras-list at cygnusx-1.org Fri Jul 22 20:46:46 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 13:46:46 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <604aa79105072212325b5e0173@mail.gmail.com> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> Message-ID: <1122065206.10442.70.camel@ws.1sttier.net> On Fri, 2005-07-22 at 15:32 -0400, Jeff Spaleta wrote: > On 7/22/05, Nathan Grennan wrote: > > Cool, though I would still prefer to see this added to the rpm. > > Regular users might want this information and having to dig it out of > > cvs isn't good. > > why do normal users need this? Packages can have a team of > maintainers... why can't issues just go into bugzilla where all the > people who are working to maintain specific packages can be informed? > Why do you need an explicit name of a person as a regular user? Not so much the name, but the e-mail address. Maybe they just want to ask a question about the package instead of filing a bug report. From orion at cora.nwra.com Fri Jul 22 20:47:47 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 14:47:47 -0600 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <200507222015.12998.jamatos@fc.up.pt> References: <42DE7D8A.30100@cora.nwra.com> <200507222015.12998.jamatos@fc.up.pt> Message-ID: <42E15B73.1090108@cora.nwra.com> Jose' Matos wrote: > On Friday 22 July 2005 17:20, Jos? Matos wrote: > >>Orion Poplawski wrote: >> >>>http://pytz.sourceforge.net/ >>> >>>Package at: >>> >>>http://www.cora.nwra.com/~orion/fedora/pytz.spec >>>http://www.cora.nwra.com/~orion/fedora/pytz-2005i-1.src.rpm > > MINOR: > > - Is it really necessary to include PKG-INFO into docs? Isn't it > redundant? > Probably, removed. > - Is it really necessary to make all python files executable? I don't see > this rule anywhere... > > If the last item is supported by any more experienced packager then > consider this as approved. > I think I did it to shutup a rpmlint warning about non-executable scripts. If it does no harm (?) I'll leave it in. > >>>python-dateutil: >>> >>>Description: >>> >>>The dateutil module provides powerful extensions to the standard >>>datetime module, available in Python 2.3+. >>> >>>https://moin.conectiva.com.br/DateUtil >>> >>>Package at: >>> >>>http://www.cora.nwra.com/~orion/fedora/python-dateutil.spec >>>http://www.cora.nwra.com/~orion/fedora/python-dateutil-0.9-1.src.rpm > > The last point is really minor so consider this package approved. > Thanks. I'll probably up to 1.0 before checkin. - Orion From ivazquez at ivazquez.net Fri Jul 22 20:52:56 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 22 Jul 2005 16:52:56 -0400 Subject: Re-Request for review: kompose In-Reply-To: <42E15601.9000403@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <200507221440.55921.dennis@ausil.us> <42E15601.9000403@cora.nwra.com> Message-ID: <1122065576.24638.3.camel@ignacio.lan> On Fri, 2005-07-22 at 14:24 -0600, Orion Poplawski wrote: > I think I've got this right: > > %install > %makeinstall > desktop-file-install --vendor=fedora --add-category=X-Fedora \ > --delete-original --dir %{buildroot}%{_datadir}/applications \ > src/kompose.desktop > rm $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop Don't use --delete-original with stuff in the BUILD dir. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 fedora-extras-list at cygnusx-1.org Fri Jul 22 20:52:19 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 13:52:19 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <1122061440.5196.70.camel@localhost.localdomain> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <1122061440.5196.70.camel@localhost.localdomain> Message-ID: <1122065539.10442.77.camel@ws.1sttier.net> On Fri, 2005-07-22 at 22:44 +0300, Ville Skytt? wrote: > There's also the CVS web interface: > http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&rev=.&view=auto > > And just to point out, depending on the use case, there are already > several sources for that for regular users, in more human friendly > format than the above: > > If one just wants to know the name of the maintainer: > https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras > > If one wants to report a bug or suggest enhancements etc, use Bugzilla. > > If one wants to know who has been working on the package lately, there's > the package changelog. Yes, there are many sources, but none as easy and straight forward as adding it as a tag to the rpm. I would expect to be able to find the information via rpm -qi. As for the changelog, I brought up in other messages why knowing the head/lead/owner of the package versus looking in the changelog and guessing the right person would be useful. I didn't know about the urls above until you pointed them out, but I have known about rpm -qi and the changelog for years. Even now that I know about them, it doesn't do other people that don't happen to read this message much good. I might have been able to find the information by digging into the fedora.redhat.com site, but rpm -qi is so much easier and I think obvious. From jspaleta at gmail.com Fri Jul 22 20:53:47 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 22 Jul 2005 16:53:47 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122065206.10442.70.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> Message-ID: <604aa791050722135344f2ef1f@mail.gmail.com> On 7/22/05, Nathan Grennan wrote: > Not so much the name, but the e-mail address. Maybe they just want to > ask a question about the package instead of filing a bug report. email addresses are typically part of the changelog entries for each change that is made. Sorry I just don't see a signficant reason to encode the current maintainer into the the package header as its own tag. There is a particularly high bar that you are going to have to meet to show a need for a new rpm header tag, so far you aren't even in the ballpark. -jef From dennis at ausil.us Fri Jul 22 21:03:19 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 22 Jul 2005 16:03:19 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42E15601.9000403@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <200507221440.55921.dennis@ausil.us> <42E15601.9000403@cora.nwra.com> Message-ID: <200507221603.20730.dennis@ausil.us> Once upon a time Friday 22 July 2005 3:24 pm, Orion Poplawski wrote: > Dennis Gilmore wrote: > > i would change > > > > CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" %configure > > --disable-rpath make > > > > to > > > > unset QTDIR || : ; . /etc/profile.d/qt.sh > > export QTLIB=${QTDIR}/lib QTINC=${QTDIR}/include > > %configure > > make %{?_smp_mflags} > > Done. Thanks for the QT stuff. no probs. > > use desktop-file-install to install your .desktop file. I dont think > > your patch to the .desktop file is needed. make sure you add > > --vendor=fedora --add-category=X-Fedora --delete-original > > I think I've got this right: > > %install > %makeinstall > desktop-file-install --vendor=fedora --add-category=X-Fedora \ > --delete-original --dir %{buildroot}%{_datadir}/applications \ > src/kompose.desktop > rm $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop you shouldnt need to remove the .desktop file thats what the --delete-original does instead of src/kompose.desktop use the full path the the installed .desktop file ie $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop > > I have used the following script from Rex Deiter in the %install section > > to catch all the language stuff > > and then use %files -f %{name}.lang instead of %files to pick up all > > the language files No Probs > Thanks! > > > kompose doesnt own /usr/share/apps/kompose/ > > Changed %files to just list %{_datadir}/apps/kompose/ ok Dennis From bugs.michael at gmx.net Fri Jul 22 21:08:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jul 2005 23:08:34 +0200 Subject: Re-Request for review: kompose In-Reply-To: <1122065576.24638.3.camel@ignacio.lan> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <200507221440.55921.dennis@ausil.us> <42E15601.9000403@cora.nwra.com> <1122065576.24638.3.camel@ignacio.lan> Message-ID: <20050722230834.7c9f10f5.bugs.michael@gmx.net> On Fri, 22 Jul 2005 16:52:56 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-07-22 at 14:24 -0600, Orion Poplawski wrote: > > I think I've got this right: > > > > %install > > %makeinstall > > desktop-file-install --vendor=fedora --add-category=X-Fedora \ > > --delete-original --dir %{buildroot}%{_datadir}/applications \ > > src/kompose.desktop > > rm $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop > > Don't use --delete-original with stuff in the BUILD dir. Can be avoided by rearranging above lines: desktop-file-install --vendor=fedora --add-category=X-Fedora \ --delete-original --dir %{buildroot}%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop From orion at cora.nwra.com Fri Jul 22 21:08:43 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 15:08:43 -0600 Subject: Re-Request for review: kompose In-Reply-To: <200507221603.20730.dennis@ausil.us> References: <42CB06AD.4040705@cora.nwra.com> <200507221440.55921.dennis@ausil.us> <42E15601.9000403@cora.nwra.com> <200507221603.20730.dennis@ausil.us> Message-ID: <42E1605B.1070708@cora.nwra.com> Dennis Gilmore wrote: > you shouldnt need to remove the .desktop file thats what the > --delete-original does instead of src/kompose.desktop use the full path the > the installed .desktop file > ie $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop Got it. However, now I don't get an icon in my menus. I think I need another --add-category to get it into a menu, but don't know what. My patch before added: Categories=Qt;KDE;Utility;X-KDE-More But don't know what is appropriate. From bugs.michael at gmx.net Fri Jul 22 21:12:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jul 2005 23:12:46 +0200 Subject: Core and Extras maintainers coordination In-Reply-To: <1122065206.10442.70.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> Message-ID: <20050722231246.001fa761.bugs.michael@gmx.net> On Fri, 22 Jul 2005 13:46:46 -0700, Nathan Grennan wrote: > > > Cool, though I would still prefer to see this added to the rpm. > > > Regular users might want this information and having to dig it out of > > > cvs isn't good. > > > > why do normal users need this? Packages can have a team of > > maintainers... why can't issues just go into bugzilla where all the > > people who are working to maintain specific packages can be informed? > > Why do you need an explicit name of a person as a regular user? > > Not so much the name, but the e-mail address. Maybe they just want to > ask a question about the package instead of filing a bug report. Please, no! For asking questions, users ought to use mailing-lists. Please let's not establish private e-mail contact as a way to contact a package author, neither for bug reports nor for questions or RFEs. Over the past weeks I've received a few private mails for packages in Fedora Extras, where I only fixed a bug or requested an all-arch rebuild. From fedora-extras-list at cygnusx-1.org Fri Jul 22 21:12:52 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 14:12:52 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <604aa791050722135344f2ef1f@mail.gmail.com> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <604aa791050722135344f2ef1f@mail.gmail.com> Message-ID: <1122066772.10442.83.camel@ws.1sttier.net> On Fri, 2005-07-22 at 16:53 -0400, Jeff Spaleta wrote: > email addresses are typically part of the changelog entries for each > change that is made. Sorry I just don't see a signficant reason to > encode the current maintainer into the the package header as its own > tag. There is a particularly high bar that you are going to have to > meet to show a need for a new rpm header tag, so far you aren't even > in the ballpark. It isn't a matter of the e-mail address, but which e-mail address. As I have already explained in other messages there can be many people, and knowing who is current and who is best to ask of many different people is a guessing game. Having a specified name and e-mail address for a package, as it seems is maintained in the owner's list is a useful piece of information. Having it buried in various websites doesn't help. As for a high bar, that seems to be the standard with all ideas that don't come from a the inner circle, sadly. From dennis at ausil.us Fri Jul 22 21:20:42 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 22 Jul 2005 16:20:42 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42E1605B.1070708@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <200507221603.20730.dennis@ausil.us> <42E1605B.1070708@cora.nwra.com> Message-ID: <200507221620.43735.dennis@ausil.us> Once upon a time Friday 22 July 2005 4:08 pm, Orion Poplawski wrote: > Dennis Gilmore wrote: > > you shouldnt need to remove the .desktop file thats what the > > --delete-original does instead of src/kompose.desktop use the full path > > the the installed .desktop file > > ie $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop > > Got it. However, now I don't get an icon in my menus. I think I need > another --add-category to get it into a menu, but don't know what. My > patch before added: > > Categories=Qt;KDE;Utility;X-KDE-More > > But don't know what is appropriate. I have a menu item in KDE under Accesories Dennis From bugs.michael at gmx.net Fri Jul 22 21:24:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jul 2005 23:24:25 +0200 Subject: Re-Request for review: kompose In-Reply-To: <42E1605B.1070708@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <200507221440.55921.dennis@ausil.us> <42E15601.9000403@cora.nwra.com> <200507221603.20730.dennis@ausil.us> <42E1605B.1070708@cora.nwra.com> Message-ID: <20050722232425.322692bf.bugs.michael@gmx.net> On Fri, 22 Jul 2005 15:08:43 -0600, Orion Poplawski wrote: > Dennis Gilmore wrote: > > you shouldnt need to remove the .desktop file thats what the > > --delete-original does instead of src/kompose.desktop use the full path the > > the installed .desktop file > > ie $RPM_BUILD_ROOT%{_datadir}/applnk/Utilities/kompose.desktop > > Got it. However, now I don't get an icon in my menus. I think I need > another --add-category to get it into a menu, but don't know what. My > patch before added: > > Categories=Qt;KDE;Utility;X-KDE-More > > But don't know what is appropriate. --add-category Application From fedora-extras-list at cygnusx-1.org Fri Jul 22 21:24:00 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 14:24:00 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <20050722231246.001fa761.bugs.michael@gmx.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> Message-ID: <1122067440.10442.93.camel@ws.1sttier.net> On Fri, 2005-07-22 at 23:12 +0200, Michael Schwendt wrote: > Please, no! For asking questions, users ought to use mailing-lists. Please > let's not establish private e-mail contact as a way to contact a package > author, neither for bug reports nor for questions or RFEs. Over the past > weeks I've received a few private mails for packages in Fedora Extras, > where I only fixed a bug or requested an all-arch rebuild. I disagree, mailing lists aren't the best choice in all cases. Some information is only known by the package maintainer and using in the mailing list in all cases assumes the person happens to notice your question out of the flood of mail the mailing lists receive. Maybe the person is on vacation and disables delivery of mailing lists. Or because there has been so much said while they were away they can't be expected to catch up. Where as a direct e-mail will be much more likely to be read. Security issues are one situation I can see some people wanting a more direct route. Personally I believe in full disclosure, but not all agree. Which brings up an interesting point. Bugzilla has a check box for security sensitive bugs. I am at least under the impression this limits access to the bug. I am curious if this works properly with extras since now not all maintainers are Red Hat employees. From pnasrat at redhat.com Fri Jul 22 21:54:44 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 22 Jul 2005 17:54:44 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122067440.10442.93.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> <1122067440.10442.93.camel@ws.1sttier.net> Message-ID: <1122069284.3697.30.camel@enki.eridu> On Fri, 2005-07-22 at 14:24 -0700, Nathan Grennan wrote: > On Fri, 2005-07-22 at 23:12 +0200, Michael Schwendt wrote: > > Please, no! For asking questions, users ought to use mailing-lists. Please > > let's not establish private e-mail contact as a way to contact a package > > author, neither for bug reports nor for questions or RFEs. Over the past > > weeks I've received a few private mails for packages in Fedora Extras, > > where I only fixed a bug or requested an all-arch rebuild. > > I disagree, mailing lists aren't the best choice in all cases. Some > information is only known by the package maintainer and using in the > mailing list in all cases assumes the person happens to notice your > question out of the flood of mail the mailing lists receive. Maybe the > person is on vacation and disables delivery of mailing lists. Or because > there has been so much said while they were away they can't be expected > to catch up. Where as a direct e-mail will be much more likely to be > read. I really disagree- and if it is necessary then you can always CC the person in your list mail to make sure but it should not be encouraged as the common method of contact. Maintainers are not a direct support forum by promoting direct email you're likely to overwhelm people with user support requests via personal email. If someone is away - another person may know the answer so a list is appropriate. I understand fedora-devel is very noisy, but fedora-maintainers and fedora-extras are pretty high quality lists. If you don't want something to get lost - raise it in bugzilla, if it's not appropriate for bugzilla raise it on the list or on #fedora-devel. Contacting the developer directly should be a last resort. > Security issues are one situation I can see some people wanting a more > direct route. Personally I believe in full disclosure, but not all > agree. Which brings up an interesting point. Bugzilla has a check box > for security sensitive bugs. I am at least under the impression this > limits access to the bug. I am curious if this works properly with > extras since now not all maintainers are Red Hat employees. This is really another conversation completely - I know various people have been looking at the possibilities for extras security teams, etc. Really we have a couple of cases here: Publically known vulnerability - in which case the developer should notice anyway and rebuild. But as it's disclosed using the list is better as someone else can push through ASAP. Zero day where discoverer wants to co-ordinate with extras (either via vendor-sec or directly). In which case obviously confidentiality is key to the issue - and we need processes for handling this. This probably does mean communicating via a response team who can escalate and maintain embargo appropriately. Communication with the developer probably is done but this is a very special case and the standard communication path. Paul From orion at cora.nwra.com Fri Jul 22 21:56:16 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 15:56:16 -0600 Subject: Re-Request for review: kompose In-Reply-To: <200507221620.43735.dennis@ausil.us> References: <42CB06AD.4040705@cora.nwra.com> <200507221603.20730.dennis@ausil.us> <42E1605B.1070708@cora.nwra.com> <200507221620.43735.dennis@ausil.us> Message-ID: <42E16B80.2050401@cora.nwra.com> Dennis Gilmore wrote: > > I have a menu item in KDE under Accesories > > Dennis > Does it have an icon? From fedora-extras-list at cygnusx-1.org Fri Jul 22 22:02:54 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 15:02:54 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <1122069284.3697.30.camel@enki.eridu> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> <1122067440.10442.93.camel@ws.1sttier.net> <1122069284.3697.30.camel@enki.eridu> Message-ID: <1122069774.13702.5.camel@ws.1sttier.net> On Fri, 2005-07-22 at 17:54 -0400, Paul Nasrat wrote: > I really disagree- and if it is necessary then you can always CC the > person in your list mail to make sure but it should not be encouraged as > the common method of contact. Maintainers are not a direct support > forum by promoting direct email you're likely to overwhelm people with > user support requests via personal email. I am not saying this should be the method used in most cases. Just that it is the proper choice in enough cases that having a maintainer tag would be nice. > If someone is away - another person may know the answer so a list is > appropriate. I understand fedora-devel is very noisy, but > fedora-maintainers and fedora-extras are pretty high quality lists. As I said before, some questions can only be answered by the maintainer. > If you don't want something to get lost - raise it in bugzilla, if it's > not appropriate for bugzilla raise it on the list or on #fedora-devel. Not all developers hang out in #fedora-devel. > Contacting the developer directly should be a last resort. I almost agree with you, but see it as more of what fits the situtation. > This is really another conversation completely - I know various people > have been looking at the possibilities for extras security teams, etc. Yes, this can be taken off into another conversation. I just happen to think of the bugzilla question while writing the previous e-mail. In the case that the response team doesn't exist, and from what you just said is my current understanding, getting in touch with the maintainer directly might be the method considered to be best by some people. From dennis at ausil.us Fri Jul 22 22:07:04 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 22 Jul 2005 17:07:04 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42E16B80.2050401@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <200507221620.43735.dennis@ausil.us> <42E16B80.2050401@cora.nwra.com> Message-ID: <200507221707.05370.dennis@ausil.us> Once upon a time Friday 22 July 2005 4:56 pm, Orion Poplawski wrote: > Dennis Gilmore wrote: > > I have a menu item in KDE under Accesories > > > > Dennis > > Does it have an icon? No it doesnt have an icon but there is a menu entry. Dennis From orion at cora.nwra.com Fri Jul 22 22:07:53 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 16:07:53 -0600 Subject: Re-Request for review: kompose In-Reply-To: <42E16B80.2050401@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <200507221603.20730.dennis@ausil.us> <42E1605B.1070708@cora.nwra.com> <200507221620.43735.dennis@ausil.us> <42E16B80.2050401@cora.nwra.com> Message-ID: <42E16E39.4060506@cora.nwra.com> Latest version: http://www.cora.nwra.com/~orion/fedora/kompose-0.5.3-2.src.rpm http://www.cora.nwra.com/~orion/fedora/kompose.spec I'm putting an icon in %{_datadir}/pixmaps to get it to display in the menu. Not sure if this is the best place. - Orion From pnasrat at redhat.com Fri Jul 22 22:15:45 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 22 Jul 2005 18:15:45 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122069774.13702.5.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> <1122067440.10442.93.camel@ws.1sttier.net> <1122069284.3697.30.camel@enki.eridu> <1122069774.13702.5.camel@ws.1sttier.net> Message-ID: <1122070545.3697.40.camel@enki.eridu> On Fri, 2005-07-22 at 15:02 -0700, Nathan Grennan wrote: > On Fri, 2005-07-22 at 17:54 -0400, Paul Nasrat wrote: > > I really disagree- and if it is necessary then you can always CC the > > person in your list mail to make sure but it should not be encouraged as > > the common method of contact. Maintainers are not a direct support > > forum by promoting direct email you're likely to overwhelm people with > > user support requests via personal email. > > I am not saying this should be the method used in most cases. Just > that it is the proper choice in enough cases that having a maintainer > tag would be nice. Speaking with my RPM hat on - this is not going to happen unless it goes in upstream. The appropriate place for that is rpm-devel-list. I don't think it's a good idea, say you have a fairly stable package in FC or FE N, maintainer changes on development tree. Between FC N and FC N+1 the maintainer retires from project, a new maintainer steps in. Having a maintainer tag be useful would mean a rebuild for no other reason than updating it as people expect to use it to find out who to talk to. We'd still need to maintain the bugzilla list for the previous fedora releases. This could be implemented with a header extension and some form of lookaside, to keep it upto date - but look at how well specspo is kept fresh, it just gets out of sync from reality. What we could do is implement a very simple xml-rpc tool to talk to bugzilla to query maintainer for a package - bug I'd consider adding a tag is the wrong thing to do here. That really shouldn't be too hard. Paul From orion at cora.nwra.com Fri Jul 22 22:49:38 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 22 Jul 2005 16:49:38 -0600 Subject: Request for sponsor and review of: lazarus and fpc In-Reply-To: <1121958861.18178.29.camel@joost> References: <1121958861.18178.29.camel@joost> Message-ID: <42E17802.7050902@cora.nwra.com> Joost van der Sluis wrote: > Hi all, > > Some time ago Jens Petersen helped me a lot with creating a package for > freepascal (fpc 2.0.0) but I didn't succeed to find a sponsor thus far. > > In the meantime an IDE which works with freepascal 2.0.0 is available. > Maybe someone want to review the lazarus package, and even sponsor me so > I can commit fpc and lazarus into the cvs. > > Lazarus: > > Lazarus is a free and opensource RAD tool for freepascal using the > lazarus component library - LCL, which is also included in this package. > > fpc: > This is what I managed to review so far: GOOD: - package name matches upstream. - GPL license and matches contents. BAD: - spec file should be ftp.spec, no version. Release should probably be "1" - COPYING not included as %doc - Missing BuildRequires: binutils, gpm-devel, some (la)tex package (may be others, I don't have mock setup) - why a "src" package? (Also note fpc-doc type in %desc). %package src Summary: Free Pascal Compiler - sources Group: Development/Languages %description src The fpc-doc package contains the sources of Freepascal, for documentation or automatical-code generation purposes. You've already got a src.rpm. POSSIBLY VERY BAD: - tar.gz of binary executables as part of the package! MINOR: - Remove commented out *Requires: lines from spec From jspaleta at gmail.com Fri Jul 22 22:51:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 22 Jul 2005 18:51:44 -0400 Subject: New Request for Review: istanbul - Now under new management In-Reply-To: <1121972013.24371.4.camel@localhost.localdomain> References: <604aa791050720142012f60201@mail.gmail.com> <1121972013.24371.4.camel@localhost.localdomain> Message-ID: <604aa791050722155157db6fad@mail.gmail.com> On 7/21/05, Ville Skytt? wrote: > Exclude. Usefulness of zero-length docs is actually less than zero. > Remove. Roughly the same applies as in above. Okay mock has been given me trouble today, its not completing the creation of the build environment install. So I've made the changes you suggested and rebuilt the package locally on my development box. http://jef.is-a-geek.com/downloads/istanbul/istanbul-0.1.1-4.i386.rpm http://jef.is-a-geek.com/downloads/istanbul/istanbul-0.1.1-4.src.rpm http://jef.is-a-geek.com/downloads/istanbul/istanbul.spec rpmlint istanbul-0.1.1-4.i386.rpm W: istanbul unstripped-binary-or-object /usr/lib/python2.4/site-packages/istanbul/extern/pytrayicon/pytrayicon.so but this is because my local build environment turns off the creation of debug packages. Anything else I need to take care of? -jef From fedora-extras-list at cygnusx-1.org Fri Jul 22 23:58:40 2005 From: fedora-extras-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 22 Jul 2005 16:58:40 -0700 Subject: Core and Extras maintainers coordination In-Reply-To: <1122070545.3697.40.camel@enki.eridu> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> <1122067440.10442.93.camel@ws.1sttier.net> <1122069284.3697.30.camel@enki.eridu> <1122069774.13702.5.camel@ws.1sttier.net> <1122070545.3697.40.camel@enki.eridu> Message-ID: <1122076720.13702.11.camel@ws.1sttier.net> On Fri, 2005-07-22 at 18:15 -0400, Paul Nasrat wrote: > Speaking with my RPM hat on - this is not going to happen unless it goes > in upstream. The appropriate place for that is rpm-devel-list. > > I don't think it's a good idea, say you have a fairly stable package in > FC or FE N, maintainer changes on development tree. Between FC N and FC > N+1 the maintainer retires from project, a new maintainer steps in. > > Having a maintainer tag be useful would mean a rebuild for no other > reason than updating it as people expect to use it to find out who to > talk to. We'd still need to maintain the bugzilla list for the previous > fedora releases. > > This could be implemented with a header extension and some form of > lookaside, to keep it upto date - but look at how well specspo is kept > fresh, it just gets out of sync from reality. > > What we could do is implement a very simple xml-rpc tool to talk to > bugzilla to query maintainer for a package - bug I'd consider adding a > tag is the wrong thing to do here. That really shouldn't be too hard. A xml-rpc tool seems reasonable. Though it has the problem of being a new thing that people have to learn about, instead a long known thing. Actually, a simpler way to deal with the tag issue I bring up would be to just use the Provider tag that already exists. It's current use of Packager : Red Hat, Inc. seems pretty worthless. If it was replaced with the maintainer, it would just work. From ville.skytta at iki.fi Sat Jul 23 08:51:22 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 23 Jul 2005 11:51:22 +0300 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <42E15A6D.5040500@cora.nwra.com> References: <42DE7D8A.30100@cora.nwra.com> <1122051364.5196.58.camel@localhost.localdomain> <42E15A6D.5040500@cora.nwra.com> Message-ID: <1122108682.4030.10.camel@localhost.localdomain> On Fri, 2005-07-22 at 14:43 -0600, Orion Poplawski wrote: > Ville Skytt? wrote: > > On Fri, 2005-07-22 at 17:20 +0100, Jos? Matos wrote: > > > > > >> My problem is that you have defined the package as noarch and then you are > >>passing -O1 to the install script, thus passing .pyo files. > > > > > > No problem there (although explicitly generating *.pyo is no longer > > necessary in FC4 and later, rpmbuild does it automatically). And *.pyo > > are relevant both for arch-dependent and noarch packages. > > > > Being very much a python newbie, I don't know about -O1 and .pyo files. > I do see that if I remove the -O1 I don't see any .pyo files in my rpm > (on FC4). I'll leave it off I guess. Apologies, that's actually done automatically in redhat-rpm-config 8.0.35 and later (ie. > FC4, not >= FC4). So you actually should take care of them yourself; just keep the -O1 and include the *.pyo the usual way or %ghost them (I don't know which of these is the current consensus, but one of them should be done). From ville.skytta at iki.fi Sat Jul 23 08:58:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 23 Jul 2005 11:58:27 +0300 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <42E15B73.1090108@cora.nwra.com> References: <42DE7D8A.30100@cora.nwra.com> <200507222015.12998.jamatos@fc.up.pt> <42E15B73.1090108@cora.nwra.com> Message-ID: <1122109107.4030.17.camel@localhost.localdomain> On Fri, 2005-07-22 at 14:47 -0600, Orion Poplawski wrote: > Jose' Matos wrote: > > - Is it really necessary to make all python files executable? I don't see > > this rule anywhere... > > > > If the last item is supported by any more experienced packager then > > consider this as approved. > > > > I think I did it to shutup a rpmlint warning about non-executable > scripts. If it does no harm (?) I'll leave it in. If these files _are_ scripts, not "libraries", and meant to be executed as such, then they should be executable. Otherwise not (except for *.so in non-noarch python packages, obviously). If these files contain a shebang (#!/usr/bin/python or the like) and a main function (def main()), it's very likely that they're runnable scripts; if not, they're probably not. From ville.skytta at iki.fi Sat Jul 23 09:02:37 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 23 Jul 2005 12:02:37 +0300 Subject: Re-Request for review: kompose In-Reply-To: <20050722224225.2573fa22.bugs.michael@gmx.net> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <20050722213231.21497185.bugs.michael@gmx.net> <42E1566B.7080001@cora.nwra.com> <20050722224225.2573fa22.bugs.michael@gmx.net> Message-ID: <1122109357.4030.21.camel@localhost.localdomain> On Fri, 2005-07-22 at 22:42 +0200, Michael Schwendt wrote: > On Fri, 22 Jul 2005 14:26:19 -0600, Orion Poplawski wrote: > > > Michael Schwendt wrote: > > > > > > No. Use %configure --disable-rpath > > > Contrary to ./configure, the %configure macro sets CFLAGS, CXXFLAGS > > > and FLAGS properly. > > > > looks like %configure sets --disable-rpath. > > It doesn't do that on FC3. Does it do that in any distro versions? From rc040203 at freenet.de Sat Jul 23 09:04:35 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 23 Jul 2005 11:04:35 +0200 Subject: Re-Request for review: kompose In-Reply-To: <1122109357.4030.21.camel@localhost.localdomain> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <20050722213231.21497185.bugs.michael@gmx.net> <42E1566B.7080001@cora.nwra.com> <20050722224225.2573fa22.bugs.michael@gmx.net> <1122109357.4030.21.camel@localhost.localdomain> Message-ID: <1122109475.2015.466.camel@mccallum.corsepiu.local> On Sat, 2005-07-23 at 12:02 +0300, Ville Skytt? wrote: > On Fri, 2005-07-22 at 22:42 +0200, Michael Schwendt wrote: > > On Fri, 22 Jul 2005 14:26:19 -0600, Orion Poplawski wrote: > > > > > Michael Schwendt wrote: > > > > > > > > No. Use %configure --disable-rpath > > > > Contrary to ./configure, the %configure macro sets CFLAGS, CXXFLAGS > > > > and FLAGS properly. > > > > > > looks like %configure sets --disable-rpath. > > > > It doesn't do that on FC3. > > Does it do that in any distro versions? If it does in any, %configure would be broken. Ralf From bugs.michael at gmx.net Sat Jul 23 09:07:31 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Jul 2005 11:07:31 +0200 Subject: Core and Extras maintainers coordination In-Reply-To: <1122067440.10442.93.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> <1122067440.10442.93.camel@ws.1sttier.net> Message-ID: <20050723110731.42003f83.bugs.michael@gmx.net> On Fri, 22 Jul 2005 14:24:00 -0700, Nathan Grennan wrote: > On Fri, 2005-07-22 at 23:12 +0200, Michael Schwendt wrote: > > Please, no! For asking questions, users ought to use mailing-lists. Please > > let's not establish private e-mail contact as a way to contact a package > > author, neither for bug reports nor for questions or RFEs. Over the past > > weeks I've received a few private mails for packages in Fedora Extras, > > where I only fixed a bug or requested an all-arch rebuild. > > I disagree, mailing lists aren't the best choice in all cases. Some > information is only known by the package maintainer and using in the > mailing list in all cases assumes the person happens to notice your > question out of the flood of mail the mailing lists receive. Maybe the > person is on vacation and disables delivery of mailing lists. This is insufficient for a good argument. If the maintainer is on vacation, the private mail is not noticed for some time. Very bad in case it is supposed to report a vulnerability. Same happens when the reporter's e-mail address or message body triggers spam projection or filtering at the recipients site. On the contrary, when reporting issues in bugzilla, it's possible for other package maintainers -- possibly co-maintainers (!) -- to take notice or even get a report via Cc. When reporting issues on mailing-lists, Fedora Community support can kick in. From bugs.michael at gmx.net Sat Jul 23 09:11:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Jul 2005 11:11:59 +0200 Subject: Re-Request for review: kompose In-Reply-To: <1122109475.2015.466.camel@mccallum.corsepiu.local> References: <42CB06AD.4040705@cora.nwra.com> <42DE7D39.4070000@cora.nwra.com> <42E13ED3.5090405@ieee.org> <20050722213231.21497185.bugs.michael@gmx.net> <42E1566B.7080001@cora.nwra.com> <20050722224225.2573fa22.bugs.michael@gmx.net> <1122109357.4030.21.camel@localhost.localdomain> <1122109475.2015.466.camel@mccallum.corsepiu.local> Message-ID: <20050723111159.2d97f226.bugs.michael@gmx.net> On Sat, 23 Jul 2005 11:04:35 +0200, Ralf Corsepius wrote: > On Sat, 2005-07-23 at 12:02 +0300, Ville Skytt? wrote: > > On Fri, 2005-07-22 at 22:42 +0200, Michael Schwendt wrote: > > > On Fri, 22 Jul 2005 14:26:19 -0600, Orion Poplawski wrote: > > > > > > > Michael Schwendt wrote: > > > > > > > > > > No. Use %configure --disable-rpath > > > > > Contrary to ./configure, the %configure macro sets CFLAGS, CXXFLAGS > > > > > and FLAGS properly. > > > > > > > > looks like %configure sets --disable-rpath. > > > > > > It doesn't do that on FC3. > > > > Does it do that in any distro versions? Would be news to me. > If it does in any, %configure would be broken. I agree. I was using FC3 when I replied to above message and was too busy/lazy to chroot into something else and check it. From pmatilai at laiskiainen.org Sat Jul 23 09:44:41 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 23 Jul 2005 02:44:41 -0700 (PDT) Subject: Core and Extras maintainers coordination In-Reply-To: <604aa79105072211035ba5886@mail.gmail.com> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <604aa79105072211035ba5886@mail.gmail.com> Message-ID: On Fri, 22 Jul 2005, Jeff Spaleta wrote: > On 7/22/05, Greg DeKoenigsberg wrote: >> So what are you proposing, exactly? Are you offering to put together the >> depcheck code that you're alluding to here, and work with Dan and Seth to >> get it integrated into the build system? > > Could the dep-reporting code being used for the daily rawhide reports > be extended to include Extras as well? My understanding is that its a > variation on what repomanage does and run across multiple arches. In It's repoclosure, not repomanage, and unmodified AFAIK. > another thread, I talked about my experience running repomanage > against core-development and extras-development on x86 and the idea of > generating something like a weekly depbreakage report. If Panu can > hack repomanage to only check the deps for the "newest" packages in a > repo that solves one of the biggest problems remaining that I can see > to using repomanage as a depbreakage reporting tool for > Core+Updates+Extras. Just had a look, adding an option to repoclosure to only check latest packages is on the order of 4 lines of code :) I'll add that on Monday when I'm back on my own box. - Panu - From ville.skytta at iki.fi Sat Jul 23 10:30:49 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 23 Jul 2005 13:30:49 +0300 Subject: Core and Extras maintainers coordination In-Reply-To: <1122076720.13702.11.camel@ws.1sttier.net> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <1122058472.10442.56.camel@ws.1sttier.net> <1122059247.3263.58.camel@laurel.intra.city-fan.org> <1122059768.10442.66.camel@ws.1sttier.net> <604aa79105072212325b5e0173@mail.gmail.com> <1122065206.10442.70.camel@ws.1sttier.net> <20050722231246.001fa761.bugs.michael@gmx.net> <1122067440.10442.93.camel@ws.1sttier.net> <1122069284.3697.30.camel@enki.eridu> <1122069774.13702.5.camel@ws.1sttier.net> <1122070545.3697.40.camel@enki.eridu> <1122076720.13702.11.camel@ws.1sttier.net> Message-ID: <1122114649.4030.28.camel@localhost.localdomain> On Fri, 2005-07-22 at 16:58 -0700, Nathan Grennan wrote: > Actually, a simpler way to deal with the tag issue I bring up would be > to just use the Provider tag that already exists. It's current use of > Packager : Red Hat, Inc. > seems pretty worthless. If it was replaced with the maintainer, it would > just work. In my opinion (agreeing wholeheartedly with contacting the maintainer in personal mail being a last resort), the above is exactly the correct value for it. For Extras, a similar one should be also added. And FWIW, the semantics of "Packager" as defined by max-rpm is the entity who _built_ the package in question, not someone who modified the specfile nor who maintains the package. From johnp at redhat.com Sat Jul 23 11:29:29 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 23 Jul 2005 07:29:29 -0400 Subject: New Request for Review: istanbul - Now under new management In-Reply-To: <604aa791050722155157db6fad@mail.gmail.com> References: <604aa791050720142012f60201@mail.gmail.com> <1121972013.24371.4.camel@localhost.localdomain> <604aa791050722155157db6fad@mail.gmail.com> Message-ID: <1122118170.3095.1.camel@localhost.localdomain> Looks good to me +1 for inclusion into extras anything I can do to help you get this in? On Fri, 2005-07-22 at 18:51 -0400, Jeff Spaleta wrote: > On 7/21/05, Ville Skytt? wrote: > > Exclude. Usefulness of zero-length docs is actually less than zero. > > Remove. Roughly the same applies as in above. > > Okay mock has been given me trouble today, its not completing the > creation of the build environment install. So I've made the changes > you suggested and rebuilt the package locally on my development box. > > http://jef.is-a-geek.com/downloads/istanbul/istanbul-0.1.1-4.i386.rpm > http://jef.is-a-geek.com/downloads/istanbul/istanbul-0.1.1-4.src.rpm > http://jef.is-a-geek.com/downloads/istanbul/istanbul.spec > > rpmlint istanbul-0.1.1-4.i386.rpm > W: istanbul unstripped-binary-or-object > /usr/lib/python2.4/site-packages/istanbul/extern/pytrayicon/pytrayicon.so > > but this is because my local build environment turns off the creation > of debug packages. > > > Anything else I need to take care of? > > -jef > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- John (J5) Palmieri From petersen at redhat.com Sat Jul 23 12:40:51 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 23 Jul 2005 21:40:51 +0900 Subject: Request for sponsor and review of: lazarus and fpc In-Reply-To: <42E17802.7050902@cora.nwra.com> References: <1121958861.18178.29.camel@joost> <42E17802.7050902@cora.nwra.com> Message-ID: <42E23AD3.7060800@redhat.com> Orion Poplawski wrote: Thanks for the review. > POSSIBLY VERY BAD: > > - tar.gz of binary executables as part of the package! This is basically needed to bootstrap fpc. Jens From jspaleta at gmail.com Sat Jul 23 14:36:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 23 Jul 2005 10:36:55 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048655.10442.12.camel@ws.1sttier.net> <1122049106.5442.7.camel@cutter> <1122051992.10442.20.camel@ws.1sttier.net> <604aa79105072211035ba5886@mail.gmail.com> Message-ID: <604aa79105072307363ea0eecf@mail.gmail.com> On 7/23/05, Panu Matilainen wrote: > It's repoclosure, not repomanage, and unmodified AFAIK. Does it just scrape the output of repoclosure and reformat it? The output format is a bit less whitespacey in the rawhide reports. -jef"repo*"spaleta From hutnick at gmail.com Sat Jul 23 15:26:57 2005 From: hutnick at gmail.com (Peter Hutnick) Date: Sat, 23 Jul 2005 09:26:57 -0600 Subject: LIRC with Streamzap Message-ID: <63a3625b050723082630d51014@mail.gmail.com> Hello, I wrote a while back about trying to get a streamzap remote working with FC3. Ville Skytt? seemed hopeful that support for streamzap would be doable in FC4 extras. Is that still the case? -Peter From ed at eh3.com Sat Jul 23 17:07:53 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 23 Jul 2005 13:07:53 -0400 Subject: Request for Review: hdf In-Reply-To: <42D837C8.3000603@cora.nwra.com> References: <42D837C8.3000603@cora.nwra.com> Message-ID: <1122138473.5322.199.camel@ernie> On Fri, 2005-07-15 at 16:25 -0600, Orion Poplawski wrote: > This is version 4 for the HDF library. > > http://www.cora.nwra.com/~orion/fedora/hdf.spec > http://www.cora.nwra.com/~orion/fedora/hdf-4.2r1-1.src.rpm > > It somewhat based on my hdf5 package, so I'm not sure there is enough > differentiation in Summary and %description. It also only work on FC4 > for now. Hi Orion, As promised, heres a review of: http://www.cora.nwra.com/~orion/fedora/hdf-4.2r1-2.src.rpm needswork: - the path in the source URL is incorrect and needs another "HDF/" in it as in: ftp://ftp.ncsa.uiuc.edu/HDF/HDF/HDF_Current/src/HDF4.2r1.tar.gz not: ftp://ftp.ncsa.uiuc.edu/HDF/HDF_Current/src/HDF%{version}.tar.gz - the package installs no shared libs so the "-p /sbin/ldconfig" can be safely removed from %post/%postun - rpmlint reports "W: hdf-devel no-documentation" which can probably be ignored a suggestion: - the two static libs (/usr/lib/libdf.a and /usr/lib/libmfhdf.a) could be placed in a /usr/lib/hdf/ dir owned by the package and this would avoid conflicts with any other packages that might want to create similarly--named libs (the "pollution of /usr/lib" problem) Good: - rpmlint OK (except for the one silly warning) - package and specfile naming OK - source matches upstream - license is BSD-ish (seems OK) and is included in %doc - code not content - specfile looks OK - builds and installs OK on FC-4 - dir ownership OK - %files looks OK - headers and libs are in devel which also looks OK - no *.la - binaries seem to work -- no segfaults Since the fixes are really minor, please feel free to do them after importing into CVS (but before requesting a build). I'll send an APPROVED message next. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From adrian at lisas.de Sat Jul 23 17:43:34 2005 From: adrian at lisas.de (Adrian Reber) Date: Sat, 23 Jul 2005 19:43:34 +0200 Subject: Request for Review: Rekall and dependencies In-Reply-To: <1121729723.32518.41.camel@localhost.localdomain> References: <1119238318.11411.8.camel@localhost.localdomain> <20050710165355.GA16609@lisas.de> <1121023144.22400.57.camel@localhost.localdomain> <20050714152252.GB10688@lisas.de> <1121729723.32518.41.camel@localhost.localdomain> Message-ID: <20050723174334.GA27516@lisas.de> On Mon, Jul 18, 2005 at 06:35:23PM -0500, Tom 'spot' Callaway wrote: > > readline-devel is also required as BR > > Fixed. New spec and SRPM: > SRPM: http://auroralinux.org/people/spot/review/xbsql-0.11-3.src.rpm > SPEC: http://auroralinux.org/people/spot/review/xbsql.spec > > Once more (with feeling), please review/approve. ;) + builds in mock + clean installation and removal + spec looks good + correct usage of -devel subpackage + source verified against upstream + rpmlint is happy + binary seems to work Looks good, APPROVED. You should probably add a Requires on xbase-devel for the xbsql-devel subpackage, as the xbsql header file uses the xbase header files. With this change you could remove the BR on xbase-devel from the rekall spec file. Adrian -- Adrian Reber http://lisas.de/~adrian/ Overload -- core meltdown sequence initiated. From jamatos at fc.up.pt Sat Jul 23 19:32:06 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 23 Jul 2005 20:32:06 +0100 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <42E15B73.1090108@cora.nwra.com> References: <42DE7D8A.30100@cora.nwra.com> <200507222015.12998.jamatos@fc.up.pt> <42E15B73.1090108@cora.nwra.com> Message-ID: <200507232032.06309.jamatos@fc.up.pt> On Friday 22 July 2005 21:47, Orion Poplawski wrote: > > - Is it really necessary to make all python files executable? I don't > > see this rule anywhere... > > > > If the last item is supported by any more experienced packager then > > consider this as approved. > > I think I did it to shutup a rpmlint warning about non-executable > scripts. If it does no harm (?) I'll leave it in. Where? Note that you don't use this in python-dateutil and everything works as expected. I noticed also that as an example rpm-python from Core: $ ll `rpm -ql rpm-python` ... /usr/lib/python2.4/site-packages/rpm: total 128 -rwxr-xr-x 1 root root 296 Jul 13 16:44 __init__.py -rw-r--r-- 1 root root 428 Jul 20 12:06 __init__.pyc -rwxr-xr-x 1 root root 115000 Jul 13 16:45 _rpmmodule.so /usr/lib/python2.4/site-packages/rpmdb: total 152 -rwxr-xr-x 1 root root 9207 Jul 13 16:44 dbobj.py -rwxr-xr-x 1 root root 2180 Jul 13 16:44 db.py -rwxr-xr-x 1 root root 5285 Jul 13 16:44 dbrecio.py -rwxr-xr-x 1 root root 8671 Jul 13 16:44 dbshelve.py -rwxr-xr-x 1 root root 25181 Jul 13 16:44 dbtables.py -rwxr-xr-x 1 root root 2802 Jul 13 16:44 dbutils.py -rwxr-xr-x 1 root root 11956 Jul 13 16:44 __init__.py -rwxr-xr-x 1 root root 66996 Jul 13 16:45 _rpmdb.so I can understand why the shared libraries are marked as executables but I don't see a reason for python files outside of a */bin directory being like that. > - Orion From jspaleta at gmail.com Sat Jul 23 19:39:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 23 Jul 2005 15:39:20 -0400 Subject: New Request for Review: istanbul - Now under new management In-Reply-To: <1122118170.3095.1.camel@localhost.localdomain> References: <604aa791050720142012f60201@mail.gmail.com> <1121972013.24371.4.camel@localhost.localdomain> <604aa791050722155157db6fad@mail.gmail.com> <1122118170.3095.1.camel@localhost.localdomain> Message-ID: <604aa79105072312397a3f0b0f@mail.gmail.com> On 7/23/05, John (J5) Palmieri wrote: > Looks good to me > > +1 for inclusion into extras > > anything I can do to help you get this in? I think at this point just an explicit approval post from you to the extras-commits-list with a copy to this thread on extras-list as per: http://www.fedoraproject.org/wiki/NewPackageProcess#head-f3f3d8619218b391eec6ac35ac48fb69801a029e -jef"Oh and if you could send me a 6 pack of Mill City Oatmill Stout that would be great"spaleta From skvidal at phy.duke.edu Sun Jul 24 07:36:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 24 Jul 2005 03:36:19 -0400 Subject: builds started Message-ID: <1122190579.12310.19.camel@cutter> Hi, all of you who have requested builds in the last couple of weeks you should start seeing all your builds from the tobuild file pushed through the system. You'll get an email for a success or failure and it should point you to build logs of the results. This should be mostly functional - let us know what breaks. -sv From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 24 09:45:01 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 24 Jul 2005 11:45:01 +0200 Subject: clamd handicraft work In-Reply-To: <80d7e4090507221328765686f8@mail.gmail.com> (Stephen J. Smoogen's message of "Fri, 22 Jul 2005 14:28:46 -0600") References: <20050630100524.1a45b781@localhost.localdomain> <80d7e4090507221328765686f8@mail.gmail.com> Message-ID: <87ek9obkrm.fsf@kosh.bigo.ensc.de> smooge at gmail.com ("Stephen J. Smoogen") writes: > Would it be useful to put something in the crontab that randomizes the > time of the update like this untested syntax? > > 0 0 * * * perl -le 'sleep rand 14400;' && {/usr/bin/freshclam --quiet > && { test -x /usr/sbin/clamav-notify-servers && exec > /usr/sbin/clamav-notify-servers || :; }} mmh... I will definitively not add a dependency on perl just to calculate a random number ;) This cron-part evolved over the various versions in the following way: 'sleep $[ RANDOM % ... ] && ...' ================================ PROs: * no additional deps * crontab remains the same across subsequent packages; so it is possible to apply changes (when it was not modified locally by the administrator) CONs: * does not work; it is impossible to use a literal '%' in crontabs * updates happen too randomly. E.g. they could be executed at 02:59, 03:00 and 08:59. The first one-minute timediff is too short and the 05:59 delay might be too long * there is a cron-instance which uglifies the 'ps' output by hanging around for several hours ;) commented crontab-line ====================== (e.g. '# MIN HOUR/3 * * * root %{_bindir}/freshclam ...') PROs: * no additional deps * should be a little bit randomly (although values like '0', '1', '23' or '42' will be used above average) CONs: * admin has to change it manually * there was no hint that it must be changed * crontab has to be changed which makes it impossible to apply changes of new versions commented crontab-line + user-notification ========================================== (same as above plus a periodic '.... mail "Activate me!" line) PROs as above, CONs minus 'there was no hint that it must be changed' substitution in %post scripts (current method) ============================================== PROs: * no additional deps CONs: * crontab will be changed which makes it impossible to apply changes of new versions * there is a %post script... I am thinking about a helper script which is similarly to the first method and gets applied as | 0 */3 * * * root || ... This script uses 'hostid' to determine the initial sleep time but can be configured by /etc/sysconfig/ also. PROs: * crontab remains stable across different versions * updates happen exactly every three hours with a constant, random delay * can be disabled without editing the crontab (that's why the '||') CONs: * there is yet-another helper script Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 24 10:00:23 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 24 Jul 2005 12:00:23 +0200 Subject: clamd handicraft work In-Reply-To: <20050720133952.GA28474@osiris.silug.org> (Steven Pritchard's message of "Wed, 20 Jul 2005 08:39:52 -0500") References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> Message-ID: <877jfgbk20.fsf@kosh.bigo.ensc.de> steve at silug.org (Steven Pritchard) writes: >> I have made my own clamav-amavis package. In the process I found the >> wrapper setup a little bit more complex than it needed to be, but got >> it working. Below is a link to my source rpm. Please review it. > > I don't really think that's a good idea. The amavisd-new package I'm > working on includes all the clamav integration. I can not say if it would be better to do the clamav-amavisd integration in an own src.rpm, or in the amavisd-new src.rpm. But I would prefer when the clamav related data and deps are in a separate (sub)package. Packaging should keep dependencies as minimal as possible: when non-core functionality has additional non-trivial deps, this functionality should go into a separate subpackage. Defining "non-trivial deps" is not trivial ;), but e.g. zlib or readline would be trivial deps, while 'perl', 'python' or other Fedora Extras packages are non-trivial deps. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tian at c-sait.net Sun Jul 24 11:01:53 2005 From: tian at c-sait.net (Christian Jodar) Date: Sun, 24 Jul 2005 13:01:53 +0200 Subject: builds started In-Reply-To: <1122190579.12310.19.camel@cutter> References: <1122190579.12310.19.camel@cutter> Message-ID: <20050724130153.34f35a13@tianbox> Hello, > You'll get an email for a success or failure and it should point you to > build logs of the results. > > This should be mostly functional - let us know what breaks. I got this error: could not check out gcfilms-5_3-1_fc4 from 4 - output was: cvs [checkout aborted]: reading from server: Connection timed out Is this related to this stuff? Should I need to do something to fix this problem? Thanks, Christian Jodar. From bugs.michael at gmx.net Sun Jul 24 11:17:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Jul 2005 13:17:35 +0200 Subject: builds started In-Reply-To: <20050724130153.34f35a13@tianbox> References: <1122190579.12310.19.camel@cutter> <20050724130153.34f35a13@tianbox> Message-ID: <20050724131735.5cdbfd77.bugs.michael@gmx.net> On Sun, 24 Jul 2005 13:01:53 +0200, Christian Jodar wrote: > Hello, > > > You'll get an email for a success or failure and it should point you to > > build logs of the results. > > > > This should be mostly functional - let us know what breaks. > > I got this error: > > could not check out gcfilms-5_3-1_fc4 from 4 - output was: > cvs [checkout aborted]: reading from server: Connection timed out > > > Is this related to this stuff? Should I need to do something to fix > this problem? I got four of those and like to see documentation for these error messages, so with the new build system we avoid confusing error messages as early as possible. From bugs.michael at gmx.net Sun Jul 24 11:24:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Jul 2005 13:24:44 +0200 Subject: builds started - could not find path /tmp/... In-Reply-To: <1122190579.12310.19.camel@cutter> References: <1122190579.12310.19.camel@cutter> Message-ID: <20050724132444.3bab85b2.bugs.michael@gmx.net> On Sun, 24 Jul 2005 03:36:19 -0400, seth vidal wrote: > Hi, > all of you who have requested builds in the last couple of weeks you > should start seeing all your builds from the tobuild file pushed through > the system. > > You'll get an email for a success or failure and it should point you to > build logs of the results. > > This should be mostly functional - let us know what breaks. Not the slightest idea what this means: Subject: Prep Error (Job 66): sylpheed-2_0_0-0_4_beta6 on development could not find path /tmp/66-sylpheed-2_0_0-0_4_beta6-1122190249/devel/devel for sylpheed-2_0_0-0_4_beta6. From ville.skytta at iki.fi Sun Jul 24 11:29:11 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 24 Jul 2005 14:29:11 +0300 Subject: LIRC with Streamzap In-Reply-To: <63a3625b050723082630d51014@mail.gmail.com> References: <63a3625b050723082630d51014@mail.gmail.com> Message-ID: <1122204551.18819.14.camel@localhost.localdomain> On Sat, 2005-07-23 at 09:26 -0600, Peter Hutnick wrote: > I wrote a while back about trying to get a streamzap remote working with FC3. > > Ville Skytt? seemed hopeful that support for streamzap would be doable > in FC4 extras. Is that still the case? Yes, it's doable in FC4 Extras, but only when there's consensus how to package and ship kernel module packages, and the required infrastructure bits (build system, yum) have been modified to support that. There was a lot of discussion about this on the fedora-packaging list a while back, but it appears to be stalled, with no definite conclusion. In the meantime, you should be able to build the LIRC kernel module package locally (which does not yet support even the agreed bits of the kernel module packaging discussions, but should get you started): grab the lirc source rpm from the FC-4 or devel repository, install kernel-devel for your kernel, and do a rpmbuild --rebuild --target i686 --with modules lirc*.src.rpm If you're not building for the currently running kernel, add also --define "kernel $kver" where $kver is the "uname -r" output of the kernel you wish to build for. And tune the --target arch above according to the arch of the kernel you're running, if not i686. This should produce a kernel-module-lirc-$uname package. But be aware that this is not much tested at all; bug reports -> bugzilla.redhat.com. From andreas at bawue.net Sun Jul 24 12:33:18 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sun, 24 Jul 2005 14:33:18 +0200 (CEST) Subject: builds started In-Reply-To: <1122190579.12310.19.camel@cutter> References: <1122190579.12310.19.camel@cutter> Message-ID: On Sun, 24 Jul 2005, seth vidal wrote: > This should be mostly functional - let us know what breaks. perl-Crypto-Blowfish just failed as it could not install perl-Crypto-CBC, a build dependency. This one was build sucessfully earlier today. Maybe it would make sense feeding the "just-built" repository to mock as well? bye, adnreas From hutnick at gmail.com Sun Jul 24 15:06:02 2005 From: hutnick at gmail.com (Peter Hutnick) Date: Sun, 24 Jul 2005 09:06:02 -0600 Subject: LIRC with Streamzap In-Reply-To: <1122204551.18819.14.camel@localhost.localdomain> References: <63a3625b050723082630d51014@mail.gmail.com> <1122204551.18819.14.camel@localhost.localdomain> Message-ID: <63a3625b050724080656fb227c@mail.gmail.com> On 7/24/05, Ville Skytt? wrote: > On Sat, 2005-07-23 at 09:26 -0600, Peter Hutnick wrote: > > > I wrote a while back about trying to get a streamzap remote working with FC3. > > > > Ville Skytt? seemed hopeful that support for streamzap would be doable > > in FC4 extras. Is that still the case? > > Yes, it's doable in FC4 Extras [snip] > In the meantime, you should be able to build the LIRC kernel module > package locally [snip] > rpmbuild --rebuild --target i686 --with modules lirc*.src.rpm [snip] This built a file kernel-module-lirc-2.6.12-1.1398_FC4-0.7.1-3.i686.rpm, which includes a working streamzap module (it loaded right up when I plugged in my IR receiver), but the existing lircd doesn't recognized "streamzap" as a driver. I ran rpmbuild --rebuild --target i686 lirc*.src.rpm and build a new lirc rpm, in the hopes that that lirc would know about streamzap, but it didn't work. I'm open to any other ideas. In any case, thanks for the help! -Peter From caillon at redhat.com Sun Jul 24 16:01:14 2005 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 24 Jul 2005 12:01:14 -0400 Subject: builds started In-Reply-To: <20050724131735.5cdbfd77.bugs.michael@gmx.net> References: <1122190579.12310.19.camel@cutter> <20050724130153.34f35a13@tianbox> <20050724131735.5cdbfd77.bugs.michael@gmx.net> Message-ID: <42E3BB4A.3090901@redhat.com> Michael Schwendt wrote: > On Sun, 24 Jul 2005 13:01:53 +0200, Christian Jodar wrote: > > >>Hello, >> >> >>>You'll get an email for a success or failure and it should point you to >>>build logs of the results. >>> >>>This should be mostly functional - let us know what breaks. >> >>I got this error: >> >>could not check out gcfilms-5_3-1_fc4 from 4 - output was: >> cvs [checkout aborted]: reading from server: Connection timed out >> >> >>Is this related to this stuff? Should I need to do something to fix >>this problem? > > > I got four of those and like to see documentation for these error > messages, so with the new build system we avoid confusing error messages > as early as possible. That is not a build system error, but a standard cvs error. It just means what it says, the checkout failed because the connection to the cvs repository timed out for some reason. There's probably nothing you can do to correct it. It needs to be corrected on the build systems themselves (or their networks) by someone with access to do so. From bugs.michael at gmx.net Sun Jul 24 19:10:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Jul 2005 21:10:33 +0200 Subject: builds started In-Reply-To: <42E3BB4A.3090901@redhat.com> References: <1122190579.12310.19.camel@cutter> <20050724130153.34f35a13@tianbox> <20050724131735.5cdbfd77.bugs.michael@gmx.net> <42E3BB4A.3090901@redhat.com> Message-ID: <20050724211033.38d8fe4c.bugs.michael@gmx.net> On Sun, 24 Jul 2005 12:01:14 -0400, Christopher Aillon wrote: > >>could not check out gcfilms-5_3-1_fc4 from 4 - output was: > >> cvs [checkout aborted]: reading from server: Connection timed out > >> > >> > >>Is this related to this stuff? Should I need to do something to fix > >>this problem? > > > > > > I got four of those and like to see documentation for these error > > messages, so with the new build system we avoid confusing error messages > > as early as possible. > > That is not a build system error, but a standard cvs error. It just means what it says, the checkout failed because the connection to the cvs repository timed out for some reason. There's probably nothing you can do to correct it. It needs to be corrected on the build systems themselves (or their networks) by someone with access to do so. > I know that it is a cvs error message, but it was reported to me by the buildsys and didn't tell what it means with regard to my build request. Is it a warning? A fatal error? With the request be requeued automatically? With the previous buildsys it was necessary to bump release and submit a new build request. Hence the question as what to do. From dennis at ausil.us Sun Jul 24 20:05:32 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 24 Jul 2005 15:05:32 -0500 Subject: Re-Request for review: kompose In-Reply-To: <42E16E39.4060506@cora.nwra.com> References: <42CB06AD.4040705@cora.nwra.com> <42E16B80.2050401@cora.nwra.com> <42E16E39.4060506@cora.nwra.com> Message-ID: <200507241505.41600.dennis@ausil.us> Once upon a time Friday 22 July 2005 5:07 pm, Orion Poplawski wrote: > Latest version: > > > http://www.cora.nwra.com/~orion/fedora/kompose-0.5.3-2.src.rpm > http://www.cora.nwra.com/~orion/fedora/kompose.spec > > I'm putting an icon in %{_datadir}/pixmaps to get it to display in the > menu. Not sure if this is the best place. > Im not sure if its the best place or best way to do it. i guess best way would be to have the icon in upstream icon sets but i guess its ok. rpmlint ../RPMS/i386/kompose-0.5.3-2.fc4.i386.rpm W: kompose incoherent-version-in-changelog 0.5.3-2 0.5.3-2.fc4 W: kompose dangling-symlink /usr/share/doc/HTML/en/kompose/common /usr/share/doc/HTML/en/common W: kompose symlink-should-be-relative /usr/share/doc/HTML/en/kompose/common /usr/share/doc/HTML/en/common the symlink thing im not 100% sure of. i found a reference at http://lists.rpmforge.net/pipermail/svn-commits/2004-September/000954.html that to me looks like rpmlint is set to ignore the symlink error will need a requires of kdebase due to html files License is ok MD5 sums match those of upstream package compiles builds and runs on X86 (FC4 and rawhide) naming ok So if someone else aggess with me on symlink issue and says its ok to put the icon in that way, and requires gets fixed then ill approve. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Jochen at herr-schmitt.de Sun Jul 24 20:34:57 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 24 Jul 2005 22:34:57 +0200 Subject: New Package: highlight-2.4 Message-ID: <20050724203457.GA24099@myhome> Hello, I want do introduced the following package to Fedora Extras: Description: A utility that converts sourcecode to HTML, XHTML, RTF, LaTeX, TeX, XSL-FO, XML or ANSI escape sequences with syntax highlighting. It supports several programming and markup languages. Language descriptions are configurable and support regular expressions. The utility offers indentation and reformatting capabilities. It is easily possible to create new language definitions and colour themes. SRPM: http://www.herr-schmitt.de/pub/highlight/highlight-2.4-1.src.rpm SPEC: http://www.herr-schmitt.de/pub/hightling/hightliht.spec Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Sun Jul 24 21:02:14 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 24 Jul 2005 16:02:14 -0500 Subject: krecepies Message-ID: <200507241602.19707.dennis@ausil.us> Hi All, im about to package up krecepies. its a frontend for a recepie database. in the backend you can have either mysql or sqlite, my thinking is that i will create the main package with the sqlite support and cretae a sub package with the mysql support. I could see most people would use it with a sqlite database. but some will want mysql. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From steve at silug.org Sun Jul 24 23:37:57 2005 From: steve at silug.org (Steven Pritchard) Date: Sun, 24 Jul 2005 18:37:57 -0500 Subject: clamd handicraft work In-Reply-To: <877jfgbk20.fsf@kosh.bigo.ensc.de> References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <877jfgbk20.fsf@kosh.bigo.ensc.de> Message-ID: <20050724233757.GA14588@osiris.silug.org> On Sun, Jul 24, 2005 at 12:00:23PM +0200, Enrico Scholz wrote: > I can not say if it would be better to do the clamav-amavisd integration > in an own src.rpm, or in the amavisd-new src.rpm. > > But I would prefer when the clamav related data and deps are in a > separate (sub)package. Packaging should keep dependencies as minimal > as possible: when non-core functionality has additional non-trivial > deps, this functionality should go into a separate subpackage. Packaging amavisd-new seems to be all about getting the dependencies right though... $ rpm -qp --requires amavisd-new-2.3.2-5.noarch.rpm | wc -l 75 Adding a couple of extra dependencies to get a fully functional (as fully as Extras can manage) amavisd-new just seems like a good idea to me. 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 skvidal at phy.duke.edu Sun Jul 24 18:56:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 24 Jul 2005 14:56:02 -0400 Subject: Core and Extras maintainers coordination In-Reply-To: <1122054154.2015.311.camel@mccallum.corsepiu.local> References: <1122046960.10442.9.camel@ws.1sttier.net> <1122047723.5442.5.camel@cutter> <1122048761.2015.296.camel@mccallum.corsepiu.local> <1122054154.2015.311.camel@mccallum.corsepiu.local> Message-ID: <1122231362.12310.54.camel@cutter> > I am quite surprised to having seen him announcing a downtime for a > weekend, but the system not having come up again since then. We had hoped it would be shorter. But b/c of some threading problems and then some other issues that came up - it just couldn't happen as quickly. > I would have expected the "buildsystem" having undergone sufficient > testing to provide a "nearly smooth" transition, before somebody would > want to make such an announcement. Well you're welcome to provide more machines and more people to do this testing with. As it stood it was a handful of us doing the testing and really only Dan doing bugfixes. > Now, I'd propose to set Seth and Dan (and who else might be involved) a > deadline (E.g. Monday morning). If they can bring the system up in > reasonable fashion, fine, I'll be amongst the first to congratulate, > then. I'd love for all sorts of things to happen but it may not all occur. Also I'd like to add that I was away from any meaningful networks all week at OLS and unable to spend nearly as much time as I might have otherwise. > If not, I would propose to back up to the old "buildsystem" and to give > them more time to bring up the new buildsystem without being > unnecessarily pressured. Easier said than done. Moreover we don't have any additional buildsystems to test this on so how exactly we do that, I don't know. Right now we're looking pretty good for the buildsystem being online this week. There looks like there is a problem with multiple cvs checkouts from the same system right now. I'm not sure that is a buildsystem issue or a cvs issue. Either way a bunch of builds will need to be resubmitted. -sv From petersen at redhat.com Mon Jul 25 05:54:36 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 25 Jul 2005 14:54:36 +0900 Subject: Request for review: tcllib In-Reply-To: <42E140F5.4000301@kobold.org> References: <42CEC83A.9090100@kobold.org> <20050716011052.63ee6296.bugs.michael@gmx.net> <42D87065.7070703@redhat.com> <42E140F5.4000301@kobold.org> Message-ID: <42E47E9C.7040207@redhat.com> Michael Thomas wrote: > The RPM that I generated was not based on the FC1 package, but on an > updated package written by Jean-Luc Fontaine. Yes, in that case you need to have the new package reviewed and approved. :) > I thought I needed to get an explicit APPROVE before I could request a > build. If that's not the case then I'll go ahead and update > owners.list, request a FC4 branch, and then request builds for both FC4 > and devel. I believe this has just been clarified on the policy page on the wiki recently. Jens From smooge at gmail.com Mon Jul 25 14:00:18 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 25 Jul 2005 08:00:18 -0600 Subject: clamd handicraft work In-Reply-To: <87ek9obkrm.fsf@kosh.bigo.ensc.de> References: <20050630100524.1a45b781@localhost.localdomain> <80d7e4090507221328765686f8@mail.gmail.com> <87ek9obkrm.fsf@kosh.bigo.ensc.de> Message-ID: <80d7e40905072507004d8f2a24@mail.gmail.com> On 7/24/05, Enrico Scholz wrote: > smooge at gmail.com ("Stephen J. Smoogen") writes: > > > Would it be useful to put something in the crontab that randomizes the > > time of the update like this untested syntax? > > > > 0 0 * * * perl -le 'sleep rand 14400;' && {/usr/bin/freshclam --quiet > > && { test -x /usr/sbin/clamav-notify-servers && exec > > /usr/sbin/clamav-notify-servers || :; }} > > mmh... I will definitively not add a dependency on perl just to calculate > a random number ;) > hmmm sorry should have used: awk 'BEGIN{x=0.0; srand()};{x=(rand()*14400); print x;}' :) > This cron-part evolved over the various versions in the following way: > > 'sleep $[ RANDOM % ... ] && ...' > ================================ > PROs: > * no additional deps > * crontab remains the same across subsequent packages; so it is > possible to apply changes (when it was not modified locally by the > administrator) > > CONs: > * does not work; it is impossible to use a literal '%' in crontabs > * updates happen too randomly. E.g. they could be executed at 02:59, > 03:00 and 08:59. The first one-minute timediff is too short and the > 05:59 delay might be too long > * there is a cron-instance which uglifies the 'ps' output by hanging > around for several hours ;) > Yeah.. the bonus is that it might end up being a better load balance on the clamd servers versus some large set picking 03:14 thinking they were being original. > > I am thinking about a helper script which is similarly to the first > method and gets applied as > > | 0 */3 * * * root || ... > > This script uses 'hostid' to determine the initial sleep time but can be > configured by /etc/sysconfig/ also. > > PROs: > * crontab remains stable across different versions > * updates happen exactly every three hours with a constant, random > delay > * can be disabled without editing the crontab (that's why the '||') > > CONs: > * there is yet-another helper script There are a couple of pros for a helper script: 1) Can be run again later by the administrator to fix the crontab entry it blown away. 2) It can help when dealing with the small school computer administrator (eg science teacher who probably doesnt really know much about computers) who got a Linux mail system set up because some students dad convinced them on the better cost value. Having to walk that person through at 2 am on these can be a pain for both. [Not that this has happened.. really.] -- Stephen J Smoogen. CSIRT/Linux System Administrator From orion at cora.nwra.com Mon Jul 25 17:46:35 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 25 Jul 2005 11:46:35 -0600 Subject: Re-Request for review: kompose In-Reply-To: <200507241505.41600.dennis@ausil.us> References: <42CB06AD.4040705@cora.nwra.com> <42E16B80.2050401@cora.nwra.com> <42E16E39.4060506@cora.nwra.com> <200507241505.41600.dennis@ausil.us> Message-ID: <42E5257B.4030206@cora.nwra.com> Dennis Gilmore wrote: > > rpmlint ../RPMS/i386/kompose-0.5.3-2.fc4.i386.rpm > W: kompose incoherent-version-in-changelog 0.5.3-2 0.5.3-2.fc4 > W: kompose > dangling-symlink /usr/share/doc/HTML/en/kompose/common /usr/share/doc/HTML/en/common > W: kompose > symlink-should-be-relative /usr/share/doc/HTML/en/kompose/common /usr/share/doc/HTML/en/common > > the symlink thing im not 100% sure of. i found a reference at > http://lists.rpmforge.net/pipermail/svn-commits/2004-September/000954.html > that to me looks like rpmlint is set to ignore the symlink error > Made the symlink relative. > will need a requires of kdebase due to html files > Done. > License is ok > MD5 sums match those of upstream package > compiles builds and runs on X86 (FC4 and rawhide) > naming ok > > > So if someone else aggess with me on symlink issue and says its ok to put the > icon in that way, and requires gets fixed then ill approve. > Latest: http://www.cora.nwra.com/~orion/fedora/kompose-0.5.3-3.src.rpm http://www.cora.nwra.com/~orion/fedora/kompose.spec No rpmlint errors for me. I can't really comment on the pixmaps issue, but it is at least no unprecented. Thanks! - Orion From orion at cora.nwra.com Mon Jul 25 17:57:53 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 25 Jul 2005 11:57:53 -0600 Subject: Request for sponsor and review of: lazarus and fpc In-Reply-To: <42E23AD3.7060800@redhat.com> References: <1121958861.18178.29.camel@joost> <42E17802.7050902@cora.nwra.com> <42E23AD3.7060800@redhat.com> Message-ID: <42E52821.1050705@cora.nwra.com> Jens Petersen wrote: > Orion Poplawski wrote: > > Thanks for the review. > > >>POSSIBLY VERY BAD: >> >> - tar.gz of binary executables as part of the package! > > > This is basically needed to bootstrap fpc. > > Jens > Yeah, but what *are* they? From a security standpoint alone putting in binaries seems suspect. Also, there is no license info for that package. I think you would need to provide the source for those binaries and build them as part of the fpc build process. I'm really not the person to answer these questions though. - Orion From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 25 17:58:10 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 25 Jul 2005 19:58:10 +0200 Subject: clamd handicraft work In-Reply-To: <87ek9obkrm.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sun, 24 Jul 2005 11:45:01 +0200") References: <20050630100524.1a45b781@localhost.localdomain> <80d7e4090507221328765686f8@mail.gmail.com> <87ek9obkrm.fsf@kosh.bigo.ensc.de> Message-ID: <871x5mbwel.fsf@kosh.bigo.ensc.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > I am thinking about a helper script which is similarly to the first > method and gets applied as > > | 0 */3 * * * root || ... > > This script uses 'hostid' ok, done. Relevant bits are at http://cvs.fedora.redhat.com/viewcvs/devel/clamav/freshclam-sleep?root=extras&rev=HEAD&view=auto http://cvs.fedora.redhat.com/viewcvs/devel/clamav/freshclam.sysconfig?root=extras&rev=HEAD&view=auto http://cvs.fedora.redhat.com/viewcvs/devel/clamav/clamav-update.cron?root=extras&rev=HEAD&view=auto Buildrequest for devel/ is filed; when there are no protests against the changes above, I will file the FC-4 and FC-3 request soon (especially because it updates to 0.86.2 with security fixes). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From paul at city-fan.org Mon Jul 25 18:53:12 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 25 Jul 2005 19:53:12 +0100 Subject: Re-Request for review: kompose In-Reply-To: <200507241505.41600.dennis@ausil.us> References: <42CB06AD.4040705@cora.nwra.com> <42E16B80.2050401@cora.nwra.com> <42E16E39.4060506@cora.nwra.com> <200507241505.41600.dennis@ausil.us> Message-ID: <1122317593.3263.92.camel@laurel.intra.city-fan.org> On Sun, 2005-07-24 at 15:05 -0500, Dennis Gilmore wrote: > Once upon a time Friday 22 July 2005 5:07 pm, Orion Poplawski wrote: > > Latest version: > > > > > > http://www.cora.nwra.com/~orion/fedora/kompose-0.5.3-2.src.rpm > > http://www.cora.nwra.com/~orion/fedora/kompose.spec > > > > I'm putting an icon in %{_datadir}/pixmaps to get it to display in the > > menu. Not sure if this is the best place. > > > Im not sure if its the best place or best way to do it. i guess best way > would be to have the icon in upstream icon sets but i guess its ok. For a gnome app I'd put the icon in %{_datadir}/icons/hicolor/48x48/apps and do the following in both %post and %postun: /bin/touch --no-create %{_datadir}/icons/hicolor || : [ -x %{_bindir}/gtk-update-icon-cache ] && %{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor || : (as per http://fedoraproject.org/wiki/ScriptletSnippets) Not sure if the same applies to KDE apps. Paul. -- Paul Howarth From Jochen at herr-schmitt.de Mon Jul 25 18:53:46 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Jul 2005 20:53:46 +0200 Subject: Request for sponsor and review of: lazarus and fpc In-Reply-To: <42E52821.1050705@cora.nwra.com> References: <1121958861.18178.29.camel@joost> <42E17802.7050902@cora.nwra.com> <42E23AD3.7060800@redhat.com> <42E52821.1050705@cora.nwra.com> Message-ID: <0ML21M-1Dx85Q45Yj-0006kR@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 25 Jul 2005 11:57:53 -0600, you wrote: >> This is basically needed to bootstrap fpc. >> >> Jens >> > >Yeah, but what *are* they? From a security standpoint alone putting in >binaries seems suspect. Also, there is no license info for that AFAIK fpc is written in Pascal. this means, you need a seed to compile the compiler. The problem is, that you didn't have a Pascal-compiler at the beginning of the build proczess. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQuU1SE9gByurcX4MEQLVYQCg2SsyqaGNKxtnlBMsnwnf4sluRG4An3T5 x7B0xK4E8YwB+nAnj/lZUrGG =3pEY -----END PGP SIGNATURE----- From Jochen at herr-schmitt.de Mon Jul 25 19:04:37 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Jul 2005 21:04:37 +0200 Subject: Question about status of the buildsystem Message-ID: <0MKwpI-1Dx8Fi1mJn-0005zA@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have anyone can help be. AFAIK a new buildsystem was installed. But after I reading http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup I'm confused waht I have to do, to initiate a build. It will be nice, if anyone have the patient to help me. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQuU3xk9gByurcX4MEQKg2ACg96R8iTyHCEIpXqACXDk6lHiX2mEAoNbH GaIH8S53AT3YiKUqgLOPQkDc =sPd0 -----END PGP SIGNATURE----- From paul at city-fan.org Mon Jul 25 19:18:08 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 25 Jul 2005 20:18:08 +0100 Subject: Question about status of the buildsystem In-Reply-To: <0MKwpI-1Dx8Fi1mJn-0005zA@mrelayeu.kundenserver.de> References: <0MKwpI-1Dx8Fi1mJn-0005zA@mrelayeu.kundenserver.de> Message-ID: <1122319088.3263.95.camel@laurel.intra.city-fan.org> On Mon, 2005-07-25 at 21:04 +0200, Jochen Schmitt wrote: > I have anyone can help be. AFAIK a new buildsystem was installed. Yes, but it's not ready for general use yet. > But after I reading > > http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup > > I'm confused waht I have to do, to initiate a build. > > It will be nice, if anyone have the patient to help me. Stay with the old buildsystem for now. http://www.fedoraproject.org/wiki/Extras/BuildRequests Your build request is likely to get done as part of the testing of the new buildsystem. Paul. -- Paul Howarth From rms at 1407.org Mon Jul 25 18:36:24 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 25 Jul 2005 19:36:24 +0100 Subject: ots In-Reply-To: <1122053200.2511.21.camel@localhost.localdomain> References: <20050717012022.60ffd702.bugs.michael@gmx.net> <1121631912.2923.29.camel@roque> <1122050885.14615.15.camel@roque> <1122053200.2511.21.camel@localhost.localdomain> Message-ID: <1122316584.2916.4.camel@roque> On Fri, 2005-07-22 at 12:26 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-22 at 17:48 +0100, Rui Miguel Seabra wrote: > > Almost a week off... is there any followup? > > Sure. I hereby make you the maintainer for OTS. Please make the change > to owners.list in CVS. Ah, great. :) But I can't :} [rms at roque extras]$ cvs co owners For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs Permission denied (publickey,keyboard-interactive). cvs [checkout aborted]: end of file from server (consult above messages if any) AFAIK I submitted my rsa_id.pub on https://admin.fedora.redhat.com/accounts/ So I suppose more is needed. Patch attached, though. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: owners.list.patch Type: text/x-patch Size: 990 bytes Desc: not available URL: -------------- 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 bugs.michael at gmx.net Mon Jul 25 19:51:03 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 25 Jul 2005 21:51:03 +0200 Subject: Question about status of the buildsystem In-Reply-To: <1122319088.3263.95.camel@laurel.intra.city-fan.org> References: <0MKwpI-1Dx8Fi1mJn-0005zA@mrelayeu.kundenserver.de> <1122319088.3263.95.camel@laurel.intra.city-fan.org> Message-ID: <20050725215103.77b4d2ae.bugs.michael@gmx.net> On Mon, 25 Jul 2005 20:18:08 +0100, Paul Howarth wrote: > On Mon, 2005-07-25 at 21:04 +0200, Jochen Schmitt wrote: > > I have anyone can help be. AFAIK a new buildsystem was installed. > > Yes, but it's not ready for general use yet. > > > But after I reading > > > > http://www.fedoraproject.org/wiki/Extras/BuildSystemClientSetup > > > > I'm confused waht I have to do, to initiate a build. > > > > It will be nice, if anyone have the patient to help me. > > Stay with the old buildsystem for now. > > http://www.fedoraproject.org/wiki/Extras/BuildRequests > > Your build request is likely to get done as part of the testing of the > new buildsystem. How "likely" is that? Last time I heard from the buildsys is 36 hours ago, when it failed to connect to cvs for three of my requests. Last status update from Seth was 36 hours ago, too. Last time packages have been released is how many days ago? There are security fixes waiting to be built and published! From fedora at tqmcube.com Mon Jul 25 21:23:19 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Mon, 25 Jul 2005 17:23:19 -0400 Subject: Request for Review: bld-0.3.3 Message-ID: <1122326599.11458.3.camel@dch.TQMcube.com> BLD stands for "blacklist daemon" and is intended to serve a blacklist. The blacklist is built by simply inserting IP addresses or by using submission rate limits based on a maximum number of submissions of the same IP address within a minimum time interval. You can build a BLD cluster by configuring the daemon to notify other similar daemon(s) every time an IP address is added to the blacklist. BLD was primarily designed to fight against dictionnary-based spams (by making the MTA report to BLD any host that tries to send a mail to an unknown user) but can be used by any program. A postfix configuration sample is included. ftp://ftp.tqmcube.com/pub/bld-0.3.3-1.src.rpm -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org Our DNSRBL - Eliminate Spam: http://www.TQMcube.com/spam_trap.htm RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From Christian.Iseli at licr.org Mon Jul 25 22:47:46 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 26 Jul 2005 00:47:46 +0200 Subject: Request for review: scmxx In-Reply-To: Your message of "Thu, 14 Jul 2005 18:10:46 +0200." Message-ID: <200507252248.j6PMltWI019750@mx3.redhat.com> andreas at bawue.net said: > I've packaged scmxx for extras and would like someone to review the > resulting spec. Good: - rpmlint is happy - name ok - spec name ok - packaging guidelines met - license ok - license matches actual license in package - license file in %doc - spec file in American English - spec file legible - source matches upstream - locale handling ok - BuildRequires ok - builds, installs, runs, and uninstalls cleanly - builds in mock - files stuff: ok - clean section ok - macro useage ok - package contains code - %doc is only doc Approved. Cheers, Christian From wart at kobold.org Mon Jul 25 22:43:01 2005 From: wart at kobold.org (Michael Thomas) Date: Mon, 25 Jul 2005 15:43:01 -0700 Subject: Request for review: tcllib In-Reply-To: <42E47E9C.7040207@redhat.com> References: <42CEC83A.9090100@kobold.org> <20050716011052.63ee6296.bugs.michael@gmx.net> <42D87065.7070703@redhat.com> <42E140F5.4000301@kobold.org> <42E47E9C.7040207@redhat.com> Message-ID: <42E56AF5.3070200@kobold.org> Jens Petersen wrote: > Michael Thomas wrote: > >>The RPM that I generated was not based on the FC1 package, but on an >>updated package written by Jean-Luc Fontaine. > > > Yes, in that case you need to have the new package reviewed and approved. :) Then I'm still looking for an approval... Are you volunteering? :) --Mike From wart at kobold.org Mon Jul 25 22:54:48 2005 From: wart at kobold.org (Michael Thomas) Date: Mon, 25 Jul 2005 15:54:48 -0700 Subject: New Package: tong Message-ID: <42E56DB8.6060406@kobold.org> I've been playing this for a few days after seeing a writeup of it in Linux Journal. %description TONG is the result of mixing Tetris and Pong, capitalizing on the essential qualities of each classic and adding new twists of its own to make an explosive chemical reaction out of it all. Homepage: http://www.nongnu.org/tong/ spec and src rpm: http://www.kobold.org/~wart/fedora/tong.spec http://www.kobold.org/~wart/fedora/tong-1.0-1.src.rpm md5sums: 797fb46342eac6d99d3eb5bb33ae60b5 tong-1.0-1.src.rpm 2caca04ee8ec6941813036b4c7095b0a tong.spec --Mike From wtogami at redhat.com Tue Jul 26 00:43:23 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 25 Jul 2005 14:43:23 -1000 Subject: New Package: tong In-Reply-To: <42E56DB8.6060406@kobold.org> References: <42E56DB8.6060406@kobold.org> Message-ID: <42E5872B.3030808@redhat.com> Michael Thomas wrote: > I've been playing this for a few days after seeing a writeup of it in > Linux Journal. > > %description > TONG is the result of mixing Tetris and Pong, capitalizing on the > essential qualities of each classic and adding new twists of its own to > make an explosive chemical reaction out of it all. > IANAL, but we had to remove games from RHL and FC in the past because they were either the same or "confusingly similar" to trademarks names like Tetris, Reversi, Othello or Sokoban. In this case it only refers to "Tetris" and maybe it would be OK if we remove the reference? I dunno. And who knows if "Pong" is still a trademark in computer games. "Tong" might be "confusingly similar". We may need legal clarification? Warren Togami wtogami at redhat.com From fedora at tqmcube.com Tue Jul 26 03:01:26 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Mon, 25 Jul 2005 23:01:26 -0400 Subject: rpms/leafnode/FC-4 leafnode.spec,1.10,1.11 In-Reply-To: <200507260046.j6Q0klbY000613@cvs-int.fedora.redhat.com> References: <200507260046.j6Q0klbY000613@cvs-int.fedora.redhat.com> Message-ID: <1122346886.11458.67.camel@dch.TQMcube.com> On Mon, 2005-07-25 at 20:46 -0400, Michael Schwendt wrote: > Author: mschwendt > > Update of /cvs/extras/rpms/leafnode/FC-4 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv596 > > Modified Files: > leafnode.spec > Log Message: > Fix non-UTF-8 in German description (#159587) and modify it a little bit. > > > Index: leafnode.spec Vielen Dank Sir. I received a successful build notice and removed it from "tobuild." Do I now "make build" again? BTW, I requested a review on a new package (bld) today. I sure hope that I'm following the procedure correctly. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org Our DNSRBL - Eliminate Spam: http://www.TQMcube.com/spam_trap.htm RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org Our DNSRBL - Eliminate Spam: http://www.TQMcube.com/spam_trap.htm RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 26 05:54:08 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 26 Jul 2005 07:54:08 +0200 Subject: clamd handicraft work In-Reply-To: <20050724233757.GA14588@osiris.silug.org> (Steven Pritchard's message of "Sun, 24 Jul 2005 18:37:57 -0500") References: <20050630100524.1a45b781@localhost.localdomain> <873br0rxur.fsf@kosh.bigo.ensc.de> <1121803090.31954.3.camel@ws.1sttier.net> <42DD5F68.6000002@redhat.com> <1121805891.8052.11.camel@ws.1sttier.net> <42DD6984.9050002@redhat.com> <1121819149.8052.41.camel@ws.1sttier.net> <20050720133952.GA28474@osiris.silug.org> <877jfgbk20.fsf@kosh.bigo.ensc.de> <20050724233757.GA14588@osiris.silug.org> Message-ID: <87wtne9kov.fsf@kosh.bigo.ensc.de> steve at silug.org (Steven Pritchard) writes: > Packaging amavisd-new seems to be all about getting the dependencies > right though... > > $ rpm -qp --requires amavisd-new-2.3.2-5.noarch.rpm | wc -l > 75 Too much dependencies are usually a sign of bad packaging ;) Please, when core amavisd works without clamav, then clamav should not be required by the core package. Put useful, but non-core functionality with extra dependencies into their own subpackages. People which want minimal systems will be very thankfully :) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 26 06:09:00 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 26 Jul 2005 08:09:00 +0200 Subject: Request for review: kismet Message-ID: <87sly29k03.fsf@kosh.bigo.ensc.de> Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and can sniff 802.11b, 802.11a, and 802.11g traffic. Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and infering the presence of nonbeaconing networks via data traffic. http://www.kismetwireless.net/ http://ensc.de/fedora/kismet.spec http://ensc.de/fedora/kismet-0.0.2005.06.R1-1.src.rpm Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From buildsys at fedoraproject.org Tue Jul 26 06:16:50 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 26 Jul 2005 02:16:50 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050726061650.07D4C7FD4@extras64> Packages built and released for Fedora Extras 3: 12 barcode-0.98-7.fc3 gaim-meanwhile-1.2.4-2.fc3 gif2png-2.5.1-1.fc3 gkrellm-freq-0.1.1-1.fc3 glabels-2.0.3-2.fc3 jhead-2.4-2.fc3 libstatgrab-0.11.1-3.fc3 lighttpd-1.3.15-1.fc3 mod_security-1.8.7-4.fc3 perl-GD-2.25-1.fc3 perl-Tk-804.027-6.fc3 synaptic-0.57.2-1.fc3 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 Tue Jul 26 06:18:28 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 26 Jul 2005 02:18:28 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050726061828.5B1B17FD4@extras64> Packages built and released for Fedora Extras 4: 20 barcode-0.98-7.fc4 bochs-2.2.1-1.fc4 dvb-apps-1.1.0-1.fc4 gaim-meanwhile-1.2.4-2.fc4 gdome2-0.8.1-1.fc4 gif2png-2.5.1-1.fc4 gkrellm-aclock-0.3.3-1.fc4 ip-sentinel-0.12-5.fc4 jhead-2.4-2.fc4 leafnode-1.11.3-2.fc4 libcddb-1.1.0-1.fc4 libstatgrab-0.11.1-3.fc4 lighttpd-1.3.15-1.fc4 mod_security-1.8.7-4.fc4 mod_suphp-0.5.2-8.fc4 perl-GD-2.25-1.fc4 perl-IO-Socket-SSL-0.97-1.fc4 synaptic-0.57.2-1.fc4 uim-0.4.7-1.fc4 x3270-3.3.4-4.fc4 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 Tue Jul 26 06:18:54 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 26 Jul 2005 02:18:54 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050726061854.A436F7FD4@extras64> Packages built and released for Fedora Extras development: 21 SoQt-1.2.0-7.fc5 barcode-0.98-7.fc5 bittorrent-4.1.2-5.fc5 bochs-2.2.1-1.fc5 brightside-1.4.0-8 bwm-ng-0.5-5.fc5 jhead-2.4-3.fc5 libcdio-0.75-1.fc5 libevent-1.1a-2.fc5 liboggz-0.9.2-1.fc5 libstatgrab-0.11.1-3.fc5 lighttpd-1.3.15-1.fc5 mod_security-1.8.7-4.fc5 nautilus-open-terminal-0.4-5.fc5 perl-Crypt-CBC-2.14-2.fc5 perl-GD-2.25-1.fc5 perl-IO-Socket-SSL-0.97-1.fc5 scim-1.3.3-1.fc5 splint-3.1.1-9.fc5 synaptic-0.57.2-1.fc5 x3270-3.3.4-4.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Tue Jul 26 06:43:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 26 Jul 2005 02:43:23 -0400 Subject: Question about status of the buildsystem In-Reply-To: <20050725215103.77b4d2ae.bugs.michael@gmx.net> References: <0MKwpI-1Dx8Fi1mJn-0005zA@mrelayeu.kundenserver.de> <1122319088.3263.95.camel@laurel.intra.city-fan.org> <20050725215103.77b4d2ae.bugs.michael@gmx.net> Message-ID: <1122360203.9641.12.camel@cutter> > How "likely" is that? Last time I heard from the buildsys is 36 hours ago, > when it failed to connect to cvs for three of my requests. Last status > update from Seth was 36 hours ago, too. I was on a plane or driving a car for about 12 of those 36 hours. The 6 hours prior to that I was sleeping and then packing. Then I slept again for another 8 hours after the long travel time. If you'd like to see a rough account of this: http://blog.sethdot.org/index.cgi/247.html Bitching about my responses based on the number of hours sense my last response is fucking ridiculous. Back off Michael. You're incredibly out of line. > Last time packages have been > released is how many days ago? There are security fixes waiting to be > built and published! I've pushed out all the successful builds and I cleaned up all the removal requests. -sv From skvidal at phy.duke.edu Tue Jul 26 06:50:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 26 Jul 2005 02:50:47 -0400 Subject: builds started In-Reply-To: <20050724211033.38d8fe4c.bugs.michael@gmx.net> References: <1122190579.12310.19.camel@cutter> <20050724130153.34f35a13@tianbox> <20050724131735.5cdbfd77.bugs.michael@gmx.net> <42E3BB4A.3090901@redhat.com> <20050724211033.38d8fe4c.bugs.michael@gmx.net> Message-ID: <1122360647.9641.15.camel@cutter> On Sun, 2005-07-24 at 21:10 +0200, Michael Schwendt wrote: > On Sun, 24 Jul 2005 12:01:14 -0400, Christopher Aillon wrote: > > > >>could not check out gcfilms-5_3-1_fc4 from 4 - output was: > > >> cvs [checkout aborted]: reading from server: Connection timed out > > >> > > >> > > >>Is this related to this stuff? Should I need to do something to fix > > >>this problem? > > > > > > > > > I got four of those and like to see documentation for these error > > > messages, so with the new build system we avoid confusing error messages > > > as early as possible. > > > > That is not a build system error, but a standard cvs error. It just means what it says, the checkout failed because the connection to the cvs repository timed out for some reason. There's probably nothing you can do to correct it. It needs to be corrected on the build systems themselves (or their networks) by someone with access to do so. > > > > I know that it is a cvs error message, but it was reported to me by the > buildsys and didn't tell what it means with regard to my build request. Is > it a warning? A fatal error? With the request be requeued automatically? > With the previous buildsys it was necessary to bump release and submit a > new build request. Hence the question as what to do. > this is no longer necessary. The failed jobs will be requeued (one way or the other) and built. the error is happening b/c we're using anon-cvs and we're overrunning the number of simultaneous connections to the cvs-server in xinetd. we can either get cvs-ssh access for the buildsys, limit the number of connections on the buildsys side or raise the number of connections on the cvs server. -sv From skvidal at phy.duke.edu Tue Jul 26 06:51:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 26 Jul 2005 02:51:43 -0400 Subject: builds started In-Reply-To: References: <1122190579.12310.19.camel@cutter> Message-ID: <1122360703.9641.17.camel@cutter> On Sun, 2005-07-24 at 14:33 +0200, Andreas Thienemann wrote: > On Sun, 24 Jul 2005, seth vidal wrote: > > > This should be mostly functional - let us know what breaks. > perl-Crypto-Blowfish just failed as it could not install perl-Crypto-CBC, > a build dependency. > > This one was build sucessfully earlier today. > Maybe it would make sense feeding the "just-built" repository to mock as > well? > we do. It was probably built out of order. The buildsys was not building in the order that things were put in. I think that will be corrected shortly. -sv From andreas at bawue.net Tue Jul 26 08:26:09 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 26 Jul 2005 10:26:09 +0200 (CEST) Subject: builds started In-Reply-To: <1122360703.9641.17.camel@cutter> References: <1122190579.12310.19.camel@cutter> <1122360703.9641.17.camel@cutter> Message-ID: On Tue, 26 Jul 2005, seth vidal wrote: > > This one was build sucessfully earlier today. Maybe it would make > > sense feeding the "just-built" repository to mock as well? > we do. Ohh. > It was probably built out of order. The buildsys was not building in the > order that things were put in. I think that will be corrected shortly. In that case something must have broken. I got the mail about the successfull Crypto-CBC build a few hours before the failed Crypto-Blowfish package. But regardless of that, is the buildsystem still in testing stage or is back in automatic mode? bye, andreas From andreas at bawue.net Tue Jul 26 09:20:42 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 26 Jul 2005 11:20:42 +0200 (CEST) Subject: Some review requests Message-ID: Hello, the following packages are still in need of review. If someone could please take a look at them and approve them, I'd be delighted. scmxx simgear qsynaptics ddrescue dd_rescue dd_rhelp scmxx: SCMxx is a console program that allows you to exchange certain types of data with mobile phones made by Siemens. Some of the data types that can be exchanged are logos, ring tones, vCalendars, phonebook entries, and short messages. Other actions like setting the time and dialling a number are also possible. SPEC: http://home.bawue.net/~ixs/scmxx/scmxx.spec SRPM: http://home.bawue.net/~ixs/scmxx/scmxx-0.8.0-1.src.rpm simgear: SimGear is a collection of libraries which provide a variety of functionality useful for building simulations, visualizations, and even games. All the SimGear code is designed to be portable across a wide variety of platforms and compilers. It has primarily been developed in support of the FlightGear project, but as development moves forward, we are generalizing the code to make more of it useful for other types of applications. The simgear-devel package contains the header files and libraries needed to develop programs that are based on the SimGear libraries. SPEC: http://home.bawue.net/~ixs/simgear/simgear.spec SRPM: http://home.bawue.net/~ixs/simgear/simgear-0.3.8-1.src.rpm Note: Even though upstream names it tarball SimGear, I choose to stay with a lovercase name, as the directory in /usr/include is lowercase. qsynaptics: QSynaptics aims to help desktop users to configure their synaptics touch pad that's commonly used in laptops. Currently it supports setting the following features: - pressure sensitivity: adjust how strong you have to press your pad to create events - tapping: adjustable tapping delay and disengageable tapping - smart tapping: switches off mouse pad for an certain delay after an keyboard event has occured - mouse button emulation: mapping of multifinger taps to certain mouse button - circular scrolling: enable or disable circular scrolling and adjusting the speed, configuring sensitive edges/corner SPEC: http://home.bawue.net/~ixs/qsynaptics/qsynaptics.spec SRPM: http://home.bawue.net/~ixs/qsynaptics/qsynaptics-0.21-1.src.rpm ddrescue: GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying hard to rescue data in case of read errors. This makes it suitable for rescuing data from media with errors, e.g. a disk with bad sectors. SPEC: http://home.bawue.net/~ixs/ddrescue/ddrescue.spec SRPM: http://home.bawue.net/~ixs/ddrescue/ddrescue-1.0-2.src.rpm dd_rescue: Like dd, dd_rescue does copy data from one file or block device to another. You can specify file positions (called seek and Skip in dd). dd_rescue does however not abort on errors in the input file, which makes it suitable for rescuing data from a medium with errors, i.e. a hard disk with some bad sectors. SPEC: http://home.bawue.net/~ixs/dd_rescue/dd_rescue.spec SRPM: http://home.bawue.net/~ixs/dd_rescue/dd_rescue-1.11-2.src.rpm dd_rhelp: dd_rhelp will use ddrescue on your entire disc, but will try to gather the maximum valid data before trying for ages on badsectors. So if you leave dd_rhelp work for infinite time, it'll have the same effect as a simple dd_rescue. But because you might not have this infinite time (this could indeed take really long in some cases... ), dd_rhelp will jump over bad sectors and rescue valid data. In the long run, it'll parse all your device with dd_rescue. SPRC: http://home.bawue.net/~ixs/dd_rhelp/dd_rhelp.spec SRPM: http://home.bawue.net/~ixs/dd_rhelp/dd_rhelp-0.0.6-2.src.rpm A note about ddrescue/dd_rescue/dd_rhelp: There exist two fault tollerant dd solutions. One is named dd_rescue, the other is named ddrescue. Both have their pros and cons. dd_rescue together with dd_rhelp (a bash helper script) looks a bit more advanced then the GNU ddrescue, but this is my personal opinion. Problem was that there is currently a ddrescue package in the fedora-extras tree, which does package dd_rescue. This is a bit confusing, as there are people who'd like ddrescue as well. My suggestion to solve this mess is to include three packages, ddrescue, dd_rescue and dd_rhelp with correct epoch and conflict tags to fix the naming mess. TIA, andreas From bugs.michael at gmx.net Tue Jul 26 09:30:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Jul 2005 11:30:59 +0200 Subject: rpms/leafnode/FC-4 leafnode.spec,1.10,1.11 In-Reply-To: <1122346886.11458.67.camel@dch.TQMcube.com> References: <200507260046.j6Q0klbY000613@cvs-int.fedora.redhat.com> <1122346886.11458.67.camel@dch.TQMcube.com> Message-ID: <20050726113059.06797ce7.bugs.michael@gmx.net> On Mon, 25 Jul 2005 23:01:26 -0400, David Cary Hart wrote: > On Mon, 2005-07-25 at 20:46 -0400, Michael Schwendt wrote: > > Author: mschwendt > > > > Update of /cvs/extras/rpms/leafnode/FC-4 > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv596 > > > > Modified Files: > > leafnode.spec > > Log Message: > > Fix non-UTF-8 in German description (#159587) and modify it a little bit. > > > > > > Index: leafnode.spec > > Vielen Dank Sir. > > I received a successful build notice and removed it from "tobuild." Do I > now "make build" again? Since your update for FC4 has been published already, I would not do another one just to get rid of bad characters in the German package description. It's a very minor issue. Decide yourself. But when you update the old package in "devel" tree, you will need another "make build" to Fedora Extras Development. And whenever the next leafnode update for FC4 may be necessary, the fix will be included finally. From joost at cnoc.nl Tue Jul 26 09:56:41 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Tue, 26 Jul 2005 11:56:41 +0200 Subject: Request for sponsor and review of: lazarus and fpc In-Reply-To: <42E52821.1050705@cora.nwra.com> References: <1121958861.18178.29.camel@joost> <42E17802.7050902@cora.nwra.com> <42E23AD3.7060800@redhat.com> <42E52821.1050705@cora.nwra.com> Message-ID: <1122371802.19171.0.camel@joost> Orion, thanks for looking into the package. On Mon, 25 Jul 2005, Orion Poplawski wrote: > Jens Petersen wrote: > > Orion Poplawski wrote: > > > > Thanks for the review. > > > > > >>POSSIBLY VERY BAD: > >> > >> - tar.gz of binary executables as part of the package! > > > > > > This is basically needed to bootstrap fpc. > > > > Jens > > > > Yeah, but what *are* they? From a security standpoint alone putting in > binaries seems suspect. Also, there is no license info for that > package. I think you would need to provide the source for those > binaries and build them as part of the fpc build process. The provided binaries are exactly the same as the binaries which are build. So after that the compiles is bootstrapped, you can check if the provided binaries are the same as the ones which are freshly compiled. Maybe I should add a readme to the binary-tarbal and a COPYING-file. Basicly the provided binary should be the 'previous' version from fpc, but then you would use a 'strange' binary, so i choosed to use the same version as the version which is build. Also the provided binaries aren't used in the final installation. So they're only in the src-package. I think that this is the best solution to introduce this new compiler. I'm looking at the other problems with the package (can't find the missing latex/tetex package. Removed almost everything, i'll find it later today and send the new version to the list) Regards, Joost. From Christian.Iseli at licr.org Tue Jul 26 11:16:25 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 26 Jul 2005 13:16:25 +0200 Subject: Some review requests In-Reply-To: Your message of "Tue, 26 Jul 2005 11:20:42 +0200." Message-ID: <200507261116.j6QBGVCF020840@mx3.redhat.com> andreas at bawue.net said: > the following packages are still in need of review. If someone could please > take a look at them and approve them, I'd be delighted. > scmxx Please see https://www.redhat.com/archives/fedora-extras-list/2005-July/msg01258.html and https://www.redhat.com/archives/fedora-extras-commits/2005-July/msg01539.html Cheers, Christian From ivazquez at ivazquez.net Tue Jul 26 11:31:31 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 26 Jul 2005 07:31:31 -0400 Subject: Request for review: nautilus-search-tool Message-ID: <1122377491.3550.14.camel@ignacio.lan> This package adds an option to the context menu in Nautilus to search for files. http://fedora.ivazquez.net/files/extras/nautilus-search-tool.spec http://fedora.ivazquez.net/files/extras/nautilus-search-tool-0.1-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 andreas at bawue.net Tue Jul 26 11:31:08 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 26 Jul 2005 13:31:08 +0200 (CEST) Subject: Some review requests In-Reply-To: <200507261116.j6QBGVCF020840@mx3.redhat.com> References: <200507261116.j6QBGVCF020840@mx3.redhat.com> Message-ID: Hello Christian, On Tue, 26 Jul 2005 Christian.Iseli at licr.org wrote: > Please see > https://www.redhat.com/archives/fedora-extras-list/2005-July/msg01258.html > and > https://www.redhat.com/archives/fedora-extras-commits/2005-July/msg01539.html Ohh cool. Thanks, I must have missed them. With exams and everything in the last weeks I haven't paid any attention at the list. ;) Importing now. bye, andreas From albi45 at yahoo.com Tue Jul 26 12:09:43 2005 From: albi45 at yahoo.com (lom loqja) Date: Tue, 26 Jul 2005 05:09:43 -0700 (PDT) Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <200507141157.34063.ermeyers@adelphia.net> Message-ID: <20050726120944.46862.qmail@web51504.mail.yahoo.com> Hi Eric, I'm new to linux world. I'm trying to find out how to install the drivers for a wireless linksys adapter WMP54G on the fedora, but i'm lost. can you please help me? thanks, Igli --- "Eric R. Meyers" wrote: > Gentlemen, and those "other" > > I've read through the thread of messages, and I've > studied Repoview, and I've > got somewhat of a handle on comps.xml. Also, I've > learned a little about > yum. > > One of the first things that Seth Vidal said to me > was "focus groups based > around what people want to do." And that's what we > are going to do in > fedora-extras. > > What do people want to do? How about, "they want to > use yum to download > stuff." So, the paradigm is to support yum > functionality, as many ways > (views) as possible. > > At this point Repoview provides two primary views of > packages > 1. Alphabetical grouping > 2. Fuzzy typal grouping (with the possible > exception of the XFCE groups) > > What Repoview does should simply be ignored. > > What we want to provide is clear (unfuzzy) grouping > with multiple views of the > packages, depending on what the user wants to do, or > how that user wants to > access, review or remove the packages. > > So here are the major views: > 1. Alphabetical grouping (I want to look at all > packages that start with 'a') > 2. Typal grouping (I want a small web-server)(or > small web-server-accessory) > 3. Logical grouping (I want to install a suite of > packages for ...) > > Comments Appreciated. > > Eric > -- > Eric R. Meyers > Systems Engineer > GPG: 0x83CE80A3 > http://users.adelphia.net/~ermeyers > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > __________________________________ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From ad+lists at uni-x.org Tue Jul 26 12:17:12 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 26 Jul 2005 14:17:12 +0200 Subject: http://fedoraproject.org/extras/4/i386/repodata/ In-Reply-To: <20050726120944.46862.qmail@web51504.mail.yahoo.com> References: <20050726120944.46862.qmail@web51504.mail.yahoo.com> Message-ID: <1122380232.25055.301.camel@serendipity.dogma.lan> Am Di, den 26.07.2005 schrieb lom loqja um 14:09: > I'm new to linux world. I'm trying to find out how to > install the drivers for a wireless linksys adapter > WMP54G on the fedora, but i'm lost. can you please > help me? thanks, > > Igli Sorry, you are on the wrong list. Please subscribe to http://www.redhat.com/mailman/listinfo/fedora-list and ask your question there. You even fouled by hijacking a very unrelated thread (replying to an existing topic and regardless of what's discussed ask your own question). So please start a fresh new mail on the Fedora users list. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 14:14:47 up 10 days, 18:47, load average: 0.15, 0.17, 0.17 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From qspencer at ieee.org Tue Jul 26 13:40:53 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 26 Jul 2005 08:40:53 -0500 Subject: Request for review: glpk Message-ID: <42E63D65.8040508@ieee.org> GLPK (Gnu Linear Programming Kit) is a library for solving linear programming (LP) problems. This is used by the development (2.9.x) and the upcoming 3.0 versions of octave. For more information about the library, see: http://www.gnu.org/software/glpk/glpk.html My SRPM can be found here: http://webpages.charter.net/qspencer/octave/glpk-4.8-1.src.rpm One note about this package. The upstream sources do not provide for building shared libraries. The maintainer has seemed somewhat unresponsive to requests on the mailing list for this (and a lot of other things), and I don't really have time or interest in maintaining patches separate from the sources, so for now this is a static-only library. I have put everything in glpk-devel, with the intention of creating a glpk package in the future if shared libs are supported. This library is not likely to be used by many applications, so for now I don't see this as a problem. -Quentin From ed at eh3.com Tue Jul 26 14:19:40 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 26 Jul 2005 10:19:40 -0400 Subject: Request for review: glpk -AND- shared vs static libs in Extras In-Reply-To: <42E63D65.8040508@ieee.org> References: <42E63D65.8040508@ieee.org> Message-ID: <1122387581.7905.28.camel@ernie> On Tue, 2005-07-26 at 08:40 -0500, Quentin Spencer wrote: > GLPK (Gnu Linear Programming Kit) is a library for solving linear > programming (LP) problems. This is used by the development (2.9.x) and > the upcoming 3.0 versions of octave. For more information about the > library, see: > http://www.gnu.org/software/glpk/glpk.html > > My SRPM can be found here: > http://webpages.charter.net/qspencer/octave/glpk-4.8-1.src.rpm > > One note about this package. The upstream sources do not provide for > building shared libraries. The maintainer has seemed somewhat > unresponsive to requests on the mailing list for this (and a lot of > other things), and I don't really have time or interest in maintaining > patches separate from the sources, so for now this is a static-only > library. I have put everything in glpk-devel, with the intention of > creating a glpk package in the future if shared libs are supported. This > library is not likely to be used by many applications, so for now I > don't see this as a problem. Hi Quentin, If someone else doesn't get to it first, I promise review glpk before Aug 1. Also, I think the removal of static libs is (or perhaps should be?) mostly aimed at Core. In Extras, its not like we're shipping a lot of ISO9660 or DVD images. All of extras truly is "optional", right? So I don't see why fighting with every package to produce shared libs makes sense in Extras -- particularly given all the work involved, the lack of upstream interest (as you point out!), and the smaller user base that many Extras packages are targeting. Or am I missing something? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From qspencer at ieee.org Tue Jul 26 14:31:03 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 26 Jul 2005 09:31:03 -0500 Subject: Request for review: glpk -AND- shared vs static libs in Extras In-Reply-To: <1122387581.7905.28.camel@ernie> References: <42E63D65.8040508@ieee.org> <1122387581.7905.28.camel@ernie> Message-ID: <42E64927.3020908@ieee.org> Ed Hill wrote: >On Tue, 2005-07-26 at 08:40 -0500, Quentin Spencer wrote: > > >>GLPK (Gnu Linear Programming Kit) is a library for solving linear >>programming (LP) problems. This is used by the development (2.9.x) and >>the upcoming 3.0 versions of octave. For more information about the >>library, see: >>http://www.gnu.org/software/glpk/glpk.html >> >>My SRPM can be found here: >>http://webpages.charter.net/qspencer/octave/glpk-4.8-1.src.rpm >> >>One note about this package. The upstream sources do not provide for >>building shared libraries. The maintainer has seemed somewhat >>unresponsive to requests on the mailing list for this (and a lot of >>other things), and I don't really have time or interest in maintaining >>patches separate from the sources, so for now this is a static-only >>library. I have put everything in glpk-devel, with the intention of >>creating a glpk package in the future if shared libs are supported. This >>library is not likely to be used by many applications, so for now I >>don't see this as a problem. >> >> > >Hi Quentin, > >If someone else doesn't get to it first, I promise review glpk before >Aug 1. > > Thanks. >Also, I think the removal of static libs is (or perhaps should be?) >mostly aimed at Core. In Extras, its not like we're shipping a lot of >ISO9660 or DVD images. All of extras truly is "optional", right? So I >don't see why fighting with every package to produce shared libs makes >sense in Extras -- particularly given all the work involved, the lack of >upstream interest (as you point out!), and the smaller user base that >many Extras packages are targeting. > >Or am I missing something? > > I think you're right about saving disk space being less critical in Extras than in core, but I also think that in general it's good to save space where possible. Yes, disk space is cheap these days, but I think we need to keep in mind the cumulative effects (on disk space and download size) of a static library if it came to be used by a lot of applications. On the other hand, if a library is only used by one application (likely the case here), then it may actually be more efficient to statically link. -Quentin From wart at kobold.org Tue Jul 26 14:33:50 2005 From: wart at kobold.org (Wart) Date: Tue, 26 Jul 2005 07:33:50 -0700 Subject: New Package: tong In-Reply-To: <42E5872B.3030808@redhat.com> References: <42E56DB8.6060406@kobold.org> <42E5872B.3030808@redhat.com> Message-ID: <42E649CE.2000802@kobold.org> Warren Togami wrote: > Michael Thomas wrote: > >> I've been playing this for a few days after seeing a writeup of it in >> Linux Journal. >> >> %description >> TONG is the result of mixing Tetris and Pong, capitalizing on the >> essential qualities of each classic and adding new twists of its own to >> make an explosive chemical reaction out of it all. >> > > IANAL, but we had to remove games from RHL and FC in the past because > they were either the same or "confusingly similar" to trademarks names > like Tetris, Reversi, Othello or Sokoban. In this case it only refers > to "Tetris" and maybe it would be OK if we remove the reference? I dunno. It would certainly be easy enough to remove the reference from the spec file. I didn't see any references to the names 'Pong' or 'Tetris' in the game itself, so that should be ok. > And who knows if "Pong" is still a trademark in computer games. "Tong" > might be "confusingly similar". We may need legal clarification? Is there a lawyer on the list who can provide guidance? --Mike From rc040203 at freenet.de Tue Jul 26 15:14:33 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Jul 2005 17:14:33 +0200 Subject: Request for review: glpk -AND- shared vs static libs in Extras In-Reply-To: <42E64927.3020908@ieee.org> References: <42E63D65.8040508@ieee.org> <1122387581.7905.28.camel@ernie> <42E64927.3020908@ieee.org> Message-ID: <1122390874.4264.284.camel@mccallum.corsepiu.local> On Tue, 2005-07-26 at 09:31 -0500, Quentin Spencer wrote: > Ed Hill wrote: > > >On Tue, 2005-07-26 at 08:40 -0500, Quentin Spencer wrote: > >>One note about this package. The upstream sources do not provide for > >>building shared libraries. T > I think you're right about saving disk space being less critical in > Extras than in core, but I also think that in general it's good to save > space where possible. Sorry, you are missing the point. Space is only minor concern, here. The actual issue is maintainability (bug fixing, upgrades) of applications having been linked against static libs. While for dynamically linked applications, replacing the shared lib underneath fixes bugs inside of the library for all applications at once, you'd have to recompile all applications which had been statically linked against a library. What makes this situation worse: An application's dependency on a static library is not visible at the rpm level. Dynamically linked applications are visible. I guess, you might not be familiar with the zlib (libz.a) disaster having happened a couple of years ago. In a nutshell: Several years ago, a serious vulnerability had been found in libz. Unfortunately, many (most) applications had been statically linked against vulnerable libz.a's. Worse, some applications had been linked against vulnerable versions of libz.a having been shipped as part of the application's sources. At this point, distributors, vendors and developers all around the world were facing the problem of identifying potentially vulnerable packages, applications and libraries. At this point, they understood why static linkage and (worse) package-local copies of common libs are harmful. FWIW: IMO, it doesn't need to be a prophet to expect sqlite to be one hot candidate for a similar disaster in near future :( Ralf From ed at eh3.com Tue Jul 26 15:29:59 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 26 Jul 2005 11:29:59 -0400 Subject: Request for review: glpk -AND- shared vs static libs in Extras In-Reply-To: <1122390874.4264.284.camel@mccallum.corsepiu.local> References: <42E63D65.8040508@ieee.org> <1122387581.7905.28.camel@ernie> <42E64927.3020908@ieee.org> <1122390874.4264.284.camel@mccallum.corsepiu.local> Message-ID: <1122391799.7905.39.camel@ernie> On Tue, 2005-07-26 at 17:14 +0200, Ralf Corsepius wrote: > > In a nutshell: Several years ago, a serious vulnerability had been found > in libz. Unfortunately, many (most) applications had been statically > linked against vulnerable libz.a's. Worse, some applications had been > linked against vulnerable versions of libz.a having been shipped as part > of the application's sources. At this point, distributors, vendors and > developers all around the world were facing the problem of identifying > potentially vulnerable packages, applications and libraries. Hi Ralf, OK, that makes a lot more sense. Thank you for the explanation! So now I'm worried about the amount of effort it will take to patch things to use shared libs if static libs are "banished" by policy. Perhaps there is some way that folks can choose between: 1) using only shared libs or 2) *documenting* (in an easily machine-parse-able fashion) the use of shared libs in all packages so that they can be automatically re-built when a dependency is updated I can understand that option (1) is probably more desirable but I shudder at the amount of work that will have to happen to crusty old makefiles, etc. to banish static libs from everything in Extras. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From rc040203 at freenet.de Tue Jul 26 15:52:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Jul 2005 17:52:50 +0200 Subject: Request for review: glpk -AND- shared vs static libs in Extras In-Reply-To: <1122391799.7905.39.camel@ernie> References: <42E63D65.8040508@ieee.org> <1122387581.7905.28.camel@ernie> <42E64927.3020908@ieee.org> <1122390874.4264.284.camel@mccallum.corsepiu.local> <1122391799.7905.39.camel@ernie> Message-ID: <1122393170.4264.294.camel@mccallum.corsepiu.local> On Tue, 2005-07-26 at 11:29 -0400, Ed Hill wrote: > So now I'm worried about the amount of effort it will take to patch > things to use shared libs if static libs are "banished" by policy. Let me put that clear: I don't want to "banished" them, I would like to see "static libs removed when possible". > Perhaps there is some way that folks can choose between: > > 1) using only shared libs or BTW: Unless a package explicitly tries to link against static libraries (--static), for libraries having been shipped as static and shared libraries, the shared libraries will be used by default. Ralf From liljencrantz at gmail.com Tue Jul 26 15:37:46 2005 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Tue, 26 Jul 2005 17:37:46 +0200 Subject: CVS account Message-ID: <7dad0d77050726083738c339eb@mail.gmail.com> Hello, Im the author of fish, a commandline shell that his included in fedora extras since a few weeks. Previously, Oliver Falk was kind enough to upload new versions of fish into CVS, but I have been unable to reach him for the last week (my emails to him bouce), and the latest fish version has yet to be included. I'm wondering if someone would be kind enough to either grant me CVS access or take on the task of maintaining the fedora version of fish. (the latter solution means less work for me) Anyway, the latsest fish srpm for fedora can be found at: http://roo.no-ip.org/fish/fedora/fish-1.12.0-1.src.rpm -- Axel From oliver at linux-kernel.at Tue Jul 26 17:23:57 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 26 Jul 2005 19:23:57 +0200 Subject: CVS account In-Reply-To: <7dad0d77050726083738c339eb@mail.gmail.com> Message-ID: <200507261723.j6QHNtfM026009@mail.linux-kernel.at> > Im the author of fish, a commandline shell that his included > in fedora extras since a few weeks. Previously, Oliver Falk > was kind enough to upload new versions of fish into CVS, but > I have been unable to reach him for the last week (my emails > to him bouce), and the latest fish version has yet to be included. Uff, do they? To which mailadr.? What error? > I'm wondering if someone would be kind enough to either grant > me CVS access or take on the task of maintaining the fedora > version of fish. > (the latter solution means less work for me) > > Anyway, the latsest fish srpm for fedora can be found at: > http://roo.no-ip.org/fish/fedora/fish-1.12.0-1.src.rpm Uploaded and requested build for FC-3 and FC-4, devel was allready done. Best, Oliver From fedora at tqmcube.com Tue Jul 26 17:25:15 2005 From: fedora at tqmcube.com (David Cary Hart) Date: Tue, 26 Jul 2005 13:25:15 -0400 Subject: New Package BLD - Request for Review Message-ID: <1122398716.2238.60.camel@dch.TQMcube.com> I fixed the spelling error and a few other minor issues detected by lint. I'm also wondering if I should have the install create yas (yet another service). Anyway, the source rpm is at: ftp://ftp.tqmcube.com/pub/bld-0.3.3-1.src.rpm BLD stands for "blacklist daemon" and is primarily intended was to fight against dictionary-based spams. BLD can also be configured to function as a Postfix policy server. -- Tired of spam? Do YOUR part: http://www.BoulderPledge.org Our DNSRBL - Eliminate Spam: http://www.TQMcube.com/spam_trap.htm RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From bugs.michael at gmx.net Tue Jul 26 17:55:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Jul 2005 19:55:10 +0200 Subject: CVS account In-Reply-To: <7dad0d77050726083738c339eb@mail.gmail.com> References: <7dad0d77050726083738c339eb@mail.gmail.com> Message-ID: <20050726195510.13a0c2c8.bugs.michael@gmx.net> On Tue, 26 Jul 2005 17:37:46 +0200, Axel Liljencrantz wrote: > Hello, > > Im the author of fish, a commandline shell that his included in fedora > extras since a few weeks. Previously, Oliver Falk was kind enough to > upload new versions of fish into CVS, but I have been unable to reach > him for the last week (my emails to him bouce), and the latest fish > version has yet to be included. > > I'm wondering if someone would be kind enough to either grant me CVS > access or take on the task of maintaining the fedora version of fish. > (the latter solution means less work for me) Does that mean you have signed up at https://admin.fedora.redhat.com/accounts/ before? From Jochen at herr-schmitt.de Tue Jul 26 19:05:44 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 26 Jul 2005 21:05:44 +0200 Subject: New Package: pdftk Message-ID: <20050726190544.GA7573@myhome> Hello, I want to introduced the PDF Tool Kit into Fedora Extras. Description: If PDF is electronic paper, then pdftk is an electronic staple-remover, hole-punch, binder, secret-decoder-ring, and X-Ray-glasses. Pdftk is a simple tool for doing everyday things with PDF documents. Keep one in the top drawer of your desktop and use it to: * Merge PDF Documents * Split PDF Pages into a New Document * Decrypt Input as Necessary (Password Required) * Encrypt Output as Desired * Burst a PDF Document into Single Pages * Report on PDF Metrics, including Metadata and Bookmarks * Uncompress and Re-Compress Page Streams * Repair Corrupted PDF (Where Possible) SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-1-src.rpm SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fredrik at dolda2000.com Wed Jul 27 01:02:01 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Wed, 27 Jul 2005 03:02:01 +0200 Subject: Fedora account Message-ID: <1122426121.16419.2.camel@pc7.dolda2000.com> Hi! I applied for a Fedora account on quite some time ago (don't remember exactly when, but it was several weeks ago), so that I can maintain icmpdn in Fedora Extras, of which I am the author. However, I have yet to receive a reply or any kind of reaction on that application. Does it normally take this long, or might there be some error? Fredrik Tolf From jspaleta at gmail.com Wed Jul 27 01:35:18 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 26 Jul 2005 21:35:18 -0400 Subject: New Request for Review: istanbul - Now under new management In-Reply-To: <604aa791050720142012f60201@mail.gmail.com> References: <604aa791050720142012f60201@mail.gmail.com> Message-ID: <604aa79105072618353cc06603@mail.gmail.com> On 7/20/05, Jeff Spaleta wrote: > Url: > http://live.gnome.org/Istanbul > > Description: > Istanbul is a desktop session recorder. You can use it to record your > desktop session and then play it back for demos, tutorials and > presentations. Sessions are recorded to ogg theora files for later > playback. Okay its been imported into fedora-extras cvs. If anyone else has any additional suggestions before I request a build in extras-development I'm all ears. -jef From bugs.michael at gmx.net Wed Jul 27 02:38:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 04:38:56 +0200 Subject: Fedora account In-Reply-To: <1122426121.16419.2.camel@pc7.dolda2000.com> References: <1122426121.16419.2.camel@pc7.dolda2000.com> Message-ID: <20050727043856.7b255970.bugs.michael@gmx.net> On Wed, 27 Jul 2005 03:02:01 +0200, Fredrik Tolf wrote: > Hi! > > I applied for a Fedora account on > quite some time ago (don't > remember exactly when, but it was several weeks ago), so that I can > maintain icmpdn in Fedora Extras, of which I am the author. > > However, I have yet to receive a reply or any kind of reaction on that > application. Does it normally take this long, or might there be some > error? > > Fredrik Tolf Do you remember at which step of the sign-up process you were? What is your user name? I think the only few cases when account requests have been rejected is when a person did not accompany the request with prior contributions or discussions about them (such as packaging on fedora-extras-list). From sopwith at redhat.com Wed Jul 27 02:43:49 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 26 Jul 2005 22:43:49 -0400 (EDT) Subject: Fedora account In-Reply-To: <1122426121.16419.2.camel@pc7.dolda2000.com> References: <1122426121.16419.2.camel@pc7.dolda2000.com> Message-ID: Did the steps you took include completing the CLA and joining the cvsextras group? Best, -- Elliot On Wed, 27 Jul 2005, Fredrik Tolf wrote: > Hi! > > I applied for a Fedora account on > quite some time ago (don't > remember exactly when, but it was several weeks ago), so that I can > maintain icmpdn in Fedora Extras, of which I am the author. > > However, I have yet to receive a reply or any kind of reaction on that > application. Does it normally take this long, or might there be some > error? > > Fredrik Tolf > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From fredrik at dolda2000.com Wed Jul 27 02:45:02 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Wed, 27 Jul 2005 04:45:02 +0200 Subject: Fedora account In-Reply-To: <20050727043856.7b255970.bugs.michael@gmx.net> References: <1122426121.16419.2.camel@pc7.dolda2000.com> <20050727043856.7b255970.bugs.michael@gmx.net> Message-ID: <1122432302.16419.7.camel@pc7.dolda2000.com> On Wed, 2005-07-27 at 04:38 +0200, Michael Schwendt wrote: > On Wed, 27 Jul 2005 03:02:01 +0200, Fredrik Tolf wrote: > > However, I have yet to receive a reply or any kind of reaction on that > > application. Does it normally take this long, or might there be some > > error? > > Do you remember at which step of the sign-up process you were? Step? Do you mean it said something like that when I submitted? In that case, I do not remember. If you mean "step" as in what I did, I applied for a new account (I had not yet gotten to request CVS access). > What is your user name? Umm... I think I chose "fredrik". > I think the only few cases when account requests have been rejected is > when a person did not accompany the request with prior contributions > or discussions about them (such as packaging on fedora-extras-list). Even if I had been rejected, I would expect to have got some kind of indication about that. :) The fact of the matter is that I didn't even get an automated message when I tried to sign up. Of course, I have no idea if I'm supposed to get an automated message as part of the process, I just thought that *if* I was supposed to get an automated message, then something has probably gone wrong. Fredrik Tolf From mike at flyn.org Wed Jul 27 03:05:24 2005 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 26 Jul 2005 22:05:24 -0500 Subject: Review request: roundup bug tracker In-Reply-To: <20050702132932.GA16181@jadzia.bu.edu> References: <20050702054951.GA20327@imp.flyn.org> <20050702132932.GA16181@jadzia.bu.edu> Message-ID: <20050727030524.GA6387@imp.flyn.org> > > 1. SELinux does not allow Apache to execute CGI scripts in > > /usr/share/roundup/cgi-bin/. How is this solved (SELinux policy is > > monolithic)? > > Yeah, executables should't go in /usr/share. > > > 2. Should installing the package restart Apache so that > > /etc/httpd/conf.d/roundup.conf is read? > > No, it shouldn't. (*Maybe* a 'service httpd graceful', but hey, you're > already having to do a bunch of this by hand anyway...) > > > 3. How should one handle initializing the Roundup database in MySQL? > > I think this needs to be done by hand instead of in a %post script. > > I think CGI scripts (and PHP apps) make difficult RPMs that need a whole > bunch of weird special-casing.... Name: roundup Description: Roundup is a simple and flexible issue-tracking system with command line, web and email interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. http://www.flyn.org/SRPMS/roundup-0.8.3-2.src.rpm http://www.flyn.org/SRPMS/roundup.spec Changed to use roundup's proxy mode. This also fixes the scripts in /usr/share issue. -- Mike :wq From bugs.michael at gmx.net Wed Jul 27 03:12:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 05:12:20 +0200 Subject: Fedora account In-Reply-To: <1122432302.16419.7.camel@pc7.dolda2000.com> References: <1122426121.16419.2.camel@pc7.dolda2000.com> <20050727043856.7b255970.bugs.michael@gmx.net> <1122432302.16419.7.camel@pc7.dolda2000.com> Message-ID: <20050727051220.43cb7fcb.bugs.michael@gmx.net> On Wed, 27 Jul 2005 04:45:02 +0200, Fredrik Tolf wrote: > On Wed, 2005-07-27 at 04:38 +0200, Michael Schwendt wrote: > > On Wed, 27 Jul 2005 03:02:01 +0200, Fredrik Tolf wrote: > > > However, I have yet to receive a reply or any kind of reaction on that > > > application. Does it normally take this long, or might there be some > > > error? > > > > Do you remember at which step of the sign-up process you were? > > Step? Do you mean it said something like that when I submitted? In that > case, I do not remember. If you mean "step" as in what I did, I applied > for a new account (I had not yet gotten to request CVS access). Yes, applying for an account is a process which consists of multiple steps. The https://admin.fedora.redhat.com/accounts/ page uses the word "step", too, at the top, and explains the individual steps which are necessary, such as requesting the Contributor License Agreement. > > What is your user name? > > Umm... I think I chose "fredrik". With username and password, you should be able to verify that at the web page. > > I think the only few cases when account requests have been rejected is > > when a person did not accompany the request with prior contributions > > or discussions about them (such as packaging on fedora-extras-list). > > Even if I had been rejected, I would expect to have got some kind of > indication about that. :) Yes, I think so. From shishz at hotpop.com Wed Jul 27 03:27:10 2005 From: shishz at hotpop.com (Zing) Date: Tue, 26 Jul 2005 23:27:10 -0400 Subject: Also about my Fedora account Message-ID: About how long does it take for the cla to clear? I've emailed and faxed my cla last week sometime and I attempted to add myself to the cvsextras group, but I get the following: 'Add' action denied. You may need to become a member of the cla_done group first. Is there some step I'm missing, or should i sit tight and wait? thanks, zing From fredrik at dolda2000.com Wed Jul 27 03:38:11 2005 From: fredrik at dolda2000.com (Fredrik Tolf) Date: Wed, 27 Jul 2005 05:38:11 +0200 Subject: Fedora account In-Reply-To: <20050727051220.43cb7fcb.bugs.michael@gmx.net> References: <1122426121.16419.2.camel@pc7.dolda2000.com> <20050727043856.7b255970.bugs.michael@gmx.net> <1122432302.16419.7.camel@pc7.dolda2000.com> <20050727051220.43cb7fcb.bugs.michael@gmx.net> Message-ID: <1122435491.16419.11.camel@pc7.dolda2000.com> On Wed, 2005-07-27 at 05:12 +0200, Michael Schwendt wrote: > On Wed, 27 Jul 2005 04:45:02 +0200, Fredrik Tolf wrote: > > > On Wed, 2005-07-27 at 04:38 +0200, Michael Schwendt wrote: > > > On Wed, 27 Jul 2005 03:02:01 +0200, Fredrik Tolf wrote: > > > > However, I have yet to receive a reply or any kind of reaction on that > > > > application. Does it normally take this long, or might there be some > > > > error? > > > > > > Do you remember at which step of the sign-up process you were? > > > > Step? Do you mean it said something like that when I submitted? In that > > case, I do not remember. If you mean "step" as in what I did, I applied > > for a new account (I had not yet gotten to request CVS access). > > Yes, applying for an account is a process which consists of multiple > steps. The https://admin.fedora.redhat.com/accounts/ page uses the > word "step", too, at the top, and explains the individual steps which > are necessary, such as requesting the Contributor License Agreement. Sorry, I misread your previous message. I missed the "at", making it "Do you remember which step of the sign-up process you were", which made it sound to me as if "Step" was some attribute assigned to me by an automated system. > > > What is your user name? > > > > Umm... I think I chose "fredrik". > > With username and password, you should be able to verify that at > the web page. Indeed. I tried the "Edit your account" link, and indeed I could log in, and I'd say it seems as though my account is approved and functional, which I find strange since I have received no notification of approval (and yes, I doublechecked the e-mail address I had given right now). Was I not supposed to get a notification that I had been approved? Fredrik Tolf From jrb at redhat.com Wed Jul 27 03:42:56 2005 From: jrb at redhat.com (Jonathan Blandford) Date: 26 Jul 2005 23:42:56 -0400 Subject: Request for review: at-poke Message-ID: I'd like to put at-poke into extras. It's a tool for testing a program's accessibility support. Spec file is attached; srpm is at: http://www.gnome.org/~jrb/files/at-poke-0.2.2-1.src.rpm Issues: * no desktop file and no translations. It's a highly specialized tool so I'm not surprised. It should be fixed upstream. * annoying crasher on close occasionally. Useful without this being fixed, but I'll try to track it down. Thanks, -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: at-poke.spec Type: application/octet-stream Size: 689 bytes Desc: spec file URL: From dennis at ausil.us Wed Jul 27 03:47:24 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 26 Jul 2005 22:47:24 -0500 Subject: Request for Review krecipes Message-ID: <200507262247.31982.dennis@ausil.us> Hi All, Could someone please review krecipes for me. SPEC: http://ausil.us/packages/krecipes.spec SRPM: http://ausil.us/packages/krecipes-0.8.1-1.fc4.src.rpm Only things im not 100% sure about is rpmlint ../RPMS/i386/krecipes-0.8.1-1.fc4.i386.rpm W: krecipes dangling-symlink /usr/share/doc/HTML/da/krecipes/common /usr/share/doc/HTML/da/common W: krecipes symlink-should-be-relative /usr/share/doc/HTML/da/krecipes/common /usr/share/doc/HTML/da/common W: krecipes dangling-symlink /usr/share/doc/HTML/pt/krecipes/common /usr/share/doc/HTML/pt/common W: krecipes symlink-should-be-relative /usr/share/doc/HTML/pt/krecipes/common /usr/share/doc/HTML/pt/common W: krecipes dangling-symlink /usr/share/doc/HTML/et/krecipes/common /usr/share/doc/HTML/et/common W: krecipes symlink-should-be-relative /usr/share/doc/HTML/et/krecipes/common /usr/share/doc/HTML/et/common W: krecipes dangling-symlink /usr/share/doc/HTML/sv/krecipes/common /usr/share/doc/HTML/sv/common W: krecipes symlink-should-be-relative /usr/share/doc/HTML/sv/krecipes/common /usr/share/doc/HTML/sv/common W: krecipes dangling-symlink /usr/share/doc/HTML/en/krecipes/common /usr/share/doc/HTML/en/common W: krecipes symlink-should-be-relative /usr/share/doc/HTML/en/krecipes/common /usr/share/doc/HTML/en/common its creating a symlink to kde documentaion some of which doesnt exist unless you have the relevent language packs installed. since i have an english only system rpm -q --whatprovides /usr/share/doc/HTML/en/common/ kdelibs-3.4.1-1 kdepim-3.4.1-0.fc4.2 kdesdk-3.4.1-0.fc4.1 kdenetwork-3.4.1-0.fc4.2 -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Wed Jul 27 03:54:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 05:54:40 +0200 Subject: New Package BLD - Request for Review In-Reply-To: <1122398716.2238.60.camel@dch.TQMcube.com> References: <1122398716.2238.60.camel@dch.TQMcube.com> Message-ID: <20050727055440.3710c4c3.bugs.michael@gmx.net> On Tue, 26 Jul 2005 13:25:15 -0400, David Cary Hart wrote: > I fixed the spelling error and a few other minor issues detected by > lint. I'm also wondering if I should have the install create yas (yet > another service). > > Anyway, the source rpm is at: > ftp://ftp.tqmcube.com/pub/bld-0.3.3-1.src.rpm $ rpmlint bld-0.3.3-1.src.rpm W: bld non-standard-group mail Suggest "Group: System Environment/Daemons". > bld-0.3.3-Makefile.in.patch The patch should delete the execution of "strip", since stripping the binaries makes rpmbuild's automatic debuginfo packages useless. > http://www.online.redhate.org/bld/ :) Don't remember having noticed that domain before. * Package %description is indented in a strange way. > %doc %_mandir/man5/* > %doc %_mandir/man8/* %doc is redundant here. %_mandir is one if the directories which is marked as %doc implicitly. The directory /var/run/bld is not included in the package. (also see further below) The Perl-based scripts in /usr/sbin could be split off into a sub-package ("bld-tools"?) as to avoid the dependency on big "perl". A bigger issue is: I believe the daemon should not run as "root", but include an initscript which runs the daemon from within an unprivileged account. The same account would also own the directory /var/run/bld. The README says: As of now, it is highly recommended to USE IT IN A SAFE ENVIRONMENT: access control is based on clients IP addresses. This is why, by default, BLD binds to localhost and should not accept requests from a machine where non-trusted users can be logged in or establish network connections to via other means (PHP for example). Such a requirement is too weak for a package-based distribution like Fedora Extras, IMO. From dennis at ausil.us Wed Jul 27 03:51:27 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 26 Jul 2005 22:51:27 -0500 Subject: request for review kmymoney2 Message-ID: <200507262251.28458.dennis@ausil.us> Hi All, Could someone please review kmymoney2 SPEC: http://ausil.us/packages/kmymoney2.spec SRPM: http://ausil.us/packages/kmymoney2-0.7.4-1.fc4.src.rpm similar issue to krecipes with symlink to kde documentation. but also not 100% sure about location of .la files kde packages put them in the main package so thats where i ave put them the devel package contains headers to build plugins. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jrb at redhat.com Wed Jul 27 03:59:52 2005 From: jrb at redhat.com (Jonathan Blandford) Date: 26 Jul 2005 23:59:52 -0400 Subject: Request for review: at-poke In-Reply-To: References: Message-ID: Jonathan Blandford writes: > I'd like to put at-poke into extras. It's a tool for testing a > program's accessibility support. Spec file is attached; srpm is at: Of course, I totally forgot Requires/BuildRequires. It should also have: BuildRequires: libgail-gnome-devel BuildRequires: gtk2-devel Requires: libgail-gnome > * annoying crasher on close occasionally. Useful without this being > fixed, but I'll try to track it down. Fixed. Have patch locally. -Jonathan From overholt at redhat.com Wed Jul 27 04:05:26 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 00:05:26 -0400 Subject: New Package: pdftk In-Reply-To: <20050726190544.GA7573@myhome> References: <20050726190544.GA7573@myhome> Message-ID: <20050727040526.GD19567@redhat.com> Hi, * Jochen Schmitt [2005-07-26 15:07]: > > SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-1-src.rpm > SPEC: http://www-herr-schmitt.de/pub/pdftk/pdftk.spec How different is this from the SRPM that Sid mentions at [1]? This is awesome, BTW! Andrew [1] http://www.accesspdf.com/article.php/20041129180128366 From overholt at redhat.com Wed Jul 27 04:34:03 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Jul 2005 00:34:03 -0400 Subject: New Package: pdftk In-Reply-To: <20050726190544.GA7573@myhome> References: <20050726190544.GA7573@myhome> Message-ID: <20050727043402.GI19567@redhat.com> * Jochen Schmitt [2005-07-26 15:07]: > > SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-1-src.rpm FWIW, this built fine for me on ppc and I've tried a few of the examples given online and they work great. Andrew From smccann at canasoft.ca Wed Jul 27 04:38:59 2005 From: smccann at canasoft.ca (Shawn McCann) Date: Tue, 26 Jul 2005 21:38:59 -0700 Subject: Request for review: libgeotiff In-Reply-To: <44048.172.16.100.62.1121666375.squirrel@ubuntu> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> <40120.172.16.100.62.1121631626.squirrel@ubuntu> <20050717224939.4f43b735.bugs.michael@gmx.net> <35161.172.16.100.62.1121645122.squirrel@ubuntu> <1121662875.4383.28.camel@mccallum.corsepiu.local> <44048.172.16.100.62.1121666375.squirrel@ubuntu> Message-ID: <42E70FE3.9010905@canasoft.ca> I'm wondering whether the last set of updates addressed the review comments adequately and whether this package is now approved for submission. Thanks Shawn Shawn McCann wrote: >Ralf, > >Thanks for the detailed comments and for taking the time to provide the >diffs. They were much easier for me to follow (I understand the comments >about the directories now). > >I've updated the spec file as you've recommended and changed the Makefile >patch to the one provided. > >Updated files are in the same place. > >SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec >SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm > >Shawn > > > > >>On Sun, 2005-07-17 at 17:05 -0700, Shawn McCann wrote: >> >> >>>OK, found a Makefile patch for this problem on newrpms.sunsite.dk >>>(thanks >>>to Rudolf Kastl) and have included it in the revised spec file. Both RPM >>>packages install successfully now. >>> >>>Regarding the second comment, not sure why you think those files are not >>>being included in the RPMS. >>> >>>/usr/share/epsg_csv is included under %files >>> %{_datadir}/epsg_csv/*.csv >>> >>>/usr/include/geotiff is included under %files devel >>> %{_includedir}/geotiff/*.h >>> >>> >>The directories %{_datadir}/epsg_csv %{_includedir}/geotiff are >>unowned. >> >>You probably want to use >>%{_datadir}/epsg_csv >>%{_includedir}/geotiff >> >> >> >>>>On Sun, 17 Jul 2005 13:20:26 -0700 (PDT), Shawn McCann wrote: >>>> >>>> >>>> >>>>>Ralf, >>>>> >>>>>Thanks for the feedback. I've updated the file to address all your >>>>>comments and posted the new version. >>>>> >>>>>SPEC: http://www.canasoft.ca/fedora/libgeotiff.spec >>>>>SRPM: http://www.canasoft.ca/fedora/libgeotiff-1.2.2-1.src.rpm >>>>> >>>>>However, I'm having one problem now. The base package includes two >>>>>executables that link to libgeotiff.so (which is why I had >>>>> >>>>> >>>libgeotiff.so >>> >>> >>>>>in the base package and included it in the Provides: directive). Now >>>>>that >>>>>I've moved libgeotiff.so back to the devel package, the base package >>>>>won't >>>>>install as it can't find libgeotiff.so. Any advice on how to deal >>>>> >>>>> >>>with >>> >>> >>>>>this? >>>>> >>>>> >>>>That's upstream sloppiness -- a bug. Library has no SONAME. It ought >>>>to be patched to get the name "libgeotiff.so.1". Then the executables >>>>will link against and depend on the proper SONAME. >>>> >>>> >>The patch sets SONAME to libgeotiff.so.1.2.2, i.e. binaries are being >>dynamically linked against libgeotiff.so.1.2.2: >> >>ldd /usr/bin/geotifcp >>... >> libgeotiff.so.1.2.2 => /usr/lib/libgeotiff.so.1.2.2 (0x007ce000) >> >>The SONAME should better be libgeotiff.so.1 >> >> >> >>>>You also want to include the following directories in the binary >>>> >>>> >>>packages: >>> >>> >>>> /usr/include/geotiff/ >>>> /usr/share/epsg_csv/ >>>> >>>> >>Exactly. This is not yet fixed yet. >> >> >> >>>>Some of Ralf's findings are not fixed yet. >>>> >>>> >>The bogus Provides: line is still present. >> >>I am proposing the patch to libgeotiff.spec and to the Makefile, below. >> >>An issue I haven't looked into: libgeotiff.so.1.2.2 contains references >>to other libraries (e.g. libtiff). So it could be reasonable to let the >>*-devel package require further *-devel packages (e.g. libtiff-devel). >> >>Ralf >> >>-- >>fedora-extras-list mailing list >>fedora-extras-list at redhat.com >>https://www.redhat.com/mailman/listinfo/fedora-extras-list >> >> >> > > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > From buildsys at fedoraproject.org Wed Jul 27 06:26:33 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jul 2005 02:26:33 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050727062633.1B4757FE5@extras64> Packages built and released for Fedora Extras 3: 26 bwm-ng-0.5-5.fc3 clamav-0.86.2-2.fc3 fedora-rpmdevtools-1.1-1.fc3 fish-1.11.1-10.fc3 fish-1.12.0-1.fc3 galculator-1.2.5-1.fc3 gif2png-2.5.1-1.fc3 gkrellm-aclock-0.3.3-1.fc3 gkrellm-freq-0.1.1-1.fc3 glabels-2.0.3-2.fc3 icmpdn-0.3-2 id3lib-3.8.3-12.fc3 ip-sentinel-0.12-5.fc3 jhead-2.4-3.fc3 libdnet-1.10-2.fc3 libstatgrab-0.11.1-3.fc3 lighttpd-1.3.15-1.fc3 mod_security-1.8.7-4.fc3 mod_suphp-0.5.2-8.fc3 moodss-20.3-1.fc3 pam_abl-0.2.2-2.fc3 perl-Crypt-CBC-2.14-2.fc3 perl-ExtUtils-XSBuilder-0.27-2.fc3 perl-Tk-804.027-6.fc3 tetex-lgrind-3.67-4.1 uim-0.4.7-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Wed Jul 27 06:42:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 02:42:42 -0400 Subject: build status Message-ID: <1122446562.3958.12.camel@cutter> All of the fc3 packages have been built and pushed. All of the other jobs for fc4 and development have been submitted to the buildsystem. you should get email for jobs you've requested and you can see what the buildsystem is doing from here: http://buildsys.fedoraproject.org/build-status/ If you see one of your jobs has completed successfully then remove it from the tobuild file, please. As soon as I get back up from sleeping for a few hours I'll check on the latest builds and figure out what failed, or not, as the case may be. And work on the web page documentation. DO NOT EMAIL ME OR CONTACT ME ON IRC WITH PROBLEMS. Email a mailing list or better yet file a bug. -sv From rc040203 at freenet.de Wed Jul 27 06:45:32 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jul 2005 08:45:32 +0200 Subject: Request for review: libgeotiff In-Reply-To: <42E70FE3.9010905@canasoft.ca> References: <1121578709.4468.23.camel@mccallum.corsepiu.local> <40120.172.16.100.62.1121631626.squirrel@ubuntu> <20050717224939.4f43b735.bugs.michael@gmx.net> <35161.172.16.100.62.1121645122.squirrel@ubuntu> <1121662875.4383.28.camel@mccallum.corsepiu.local> <44048.172.16.100.62.1121666375.squirrel@ubuntu> <42E70FE3.9010905@canasoft.ca> Message-ID: <1122446732.4264.386.camel@mccallum.corsepiu.local> On Tue, 2005-07-26 at 21:38 -0700, Shawn McCann wrote: > I'm wondering whether the last set of updates addressed the review > comments adequately and whether this package is now approved for submission. I don't consider my remarks on your package to qualify as formal review. IMO, this package still needs further modifications, because rpmlint isn't statisfied with it: # rpmlint libgeotiff-1.2.2-1.i386.rpm E: libgeotiff description-line-too-long Libgeotiff is a public domain library normally hosted on top of libtiff for reading, and writing GeoTIFF information tags. W: libgeotiff invalid-license MIT/X Consortium License E: libgeotiff invalid-ldconfig-symlink /usr/lib/libgeotiff.so.1.2.2 libgeotiff.so.1.2 E: libgeotiff shlib-with-non-pic-code /usr/lib/libgeotiff.so.1.2.2 E: libgeotiff library-not-linked-against-libc /usr/lib/libgeotiff.so.1.2.2 E: libgeotiff zero-length /usr/share/epsg_csv/codes.csv Unfortunately, I haven't had enough time to look into details, yet. Ralf From pmatilai at laiskiainen.org Wed Jul 27 07:29:02 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 27 Jul 2005 00:29:02 -0700 (PDT) Subject: build status In-Reply-To: <1122446562.3958.12.camel@cutter> References: <1122446562.3958.12.camel@cutter> Message-ID: On Wed, 27 Jul 2005, seth vidal wrote: > All of the fc3 packages have been built and pushed. > All of the other jobs for fc4 and development have been submitted to the > buildsystem. > > you should get email for jobs you've requested and you can see what the > buildsystem is doing from here: > > http://buildsys.fedoraproject.org/build-status/ Wow, now that's cool! :) - Panu - From ondrejj at salstar.sk Wed Jul 27 07:36:51 2005 From: ondrejj at salstar.sk (Jan ONDREJ (SAL)) Date: Wed, 27 Jul 2005 09:36:51 +0200 Subject: build status In-Reply-To: References: <1122446562.3958.12.camel@cutter> Message-ID: <20050727073651.GG2601@salstar.sk> On Wed, Jul 27, 2005 at 12:29:02AM -0700, Panu Matilainen wrote: > On Wed, 27 Jul 2005, seth vidal wrote: > > >All of the fc3 packages have been built and pushed. > >All of the other jobs for fc4 and development have been submitted to the > >buildsystem. > > > >you should get email for jobs you've requested and you can see what the > >buildsystem is doing from here: > > > >http://buildsys.fedoraproject.org/build-status/ > > Wow, now that's cool! :) Yes, very cool. :-) But can anybody tell me, why "galeon" is still not built for extras4? There are dependency problems with latest Mozilla from fedora core updates and galeon. Users can't update to latest Mozilla+Galeon for these problems. There are also problems with latest updates for fedora extras 4: Error: Missing Dependency: libcddb.so.0 is needed by package libcdio There is a new libcddb release which breaks compatibility and there is not new libcdio. I see, that libcdio is now built for development, but not for a stable release. Why you are building packages for development and not fixing dependency problems for stable releases? :( What are "JOB ID's" on build-status page? Galeon has ID 2 and other packages are built, but this stable still not (I am watching build status only aprox. a hour). SAL From jnovy at redhat.com Wed Jul 27 08:59:32 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 27 Jul 2005 10:59:32 +0200 Subject: nedit package imported Message-ID: <1122454772.22689.21.camel@obelix.redhat.usu> Hello all, after a little spec file tuning of nedit discussed here I imported the new nedit-5.5 package to Fedora Extras devel and started the initial build. Because this is a former Fedora Core package: https://www.redhat.com/archives/fedora-extras-list/2005- July/msg01075.html there's no explicit approval needed before inclusion. Thanks again for reviewing this package. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ The worst evil in the world is refusal to think. From bugs.michael at gmx.net Wed Jul 27 11:30:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 13:30:25 +0200 Subject: build status In-Reply-To: <1122446562.3958.12.camel@cutter> References: <1122446562.3958.12.camel@cutter> Message-ID: <20050727133025.717583ea.bugs.michael@gmx.net> On Wed, 27 Jul 2005 02:42:42 -0400, seth vidal wrote: > All of the fc3 packages have been built and pushed. > All of the other jobs for fc4 and development have been submitted to the > buildsystem. > > you should get email for jobs you've requested and you can see what the > buildsystem is doing from here: > > http://buildsys.fedoraproject.org/build-status/ > > If you see one of your jobs has completed successfully then remove it > from the tobuild file, please. > > As soon as I get back up from sleeping for a few hours I'll check on the > latest builds and figure out what failed, or not, as the case may be. > And work on the web page documentation. > > DO NOT EMAIL ME OR CONTACT ME ON IRC WITH PROBLEMS. Email a mailing list > or better yet file a bug. What would be interesting to learn is what buildsys messages require action by the packager. I've yet to see a single success report. Should I have received a message for a successful build? All I seem to get is error messages, such as this latest batch, each in a separate "Prep Error" message: could not find path /tmp/102-inkscape-0_42-1_fc5-1122445555/devel/devel for inkscape-0_42-1_fc5. could not find path /tmp/107-hping2-2_0_0-0_5_rc3-1122445576/devel/devel for hping2-2_0_0-0_5_rc3. could not find path /tmp/100-meld-1_0_0-1_fc5-1122445555/devel/devel for meld-1_0_0-1_fc5. could not find path /tmp/72-tetex-lgrind-3_67-7-1122445475/devel/devel for tetex-lgrind-3_67-7. could not find path /tmp/71-freeze-2_5_0-4-1122445475/devel/devel for freeze-2_5_0-4. could not find path /tmp/70-cksfv-1_3-4-1122445473/devel/devel for cksfv-1_3-4. could not find path /tmp/36-sylpheed-2_0_0-0_4_beta6-1122445432/devel/devel for sylpheed-2_0_0-0_4_beta6. From ivazquez at ivazquez.net Wed Jul 27 11:40:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Jul 2005 07:40:52 -0400 Subject: New Package: pdftk In-Reply-To: <20050726190544.GA7573@myhome> References: <20050726190544.GA7573@myhome> Message-ID: <1122464452.3550.26.camel@ignacio.lan> On Tue, 2005-07-26 at 21:05 +0200, Jochen Schmitt wrote: > SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-1-src.rpm > SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec - Don't need to compress man pages - Don't need pdftk.1.notes - No copy of GPL included - Don't need explicit Requires of libgcj + Builds in mock ? What about dist rights of the contents of java_libs/com/lowagie/text/pdf/fonts? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 dennis at ausil.us Wed Jul 27 11:37:35 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 27 Jul 2005 06:37:35 -0500 Subject: build status In-Reply-To: <20050727133025.717583ea.bugs.michael@gmx.net> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> Message-ID: <200507270637.43447.dennis@ausil.us> Once upon a time Wednesday 27 July 2005 6:30 am, Michael Schwendt wrote: > > What would be interesting to learn is what buildsys messages require action > by the packager. I've yet to see a single success report. Should I have > received a message for a successful build? Yes you get a email stating that the build was successful. right now Seth is going to re-queue failed builds and Dan is going to work on some code to requeue failed builds automatically. Well that was what was discussed on irc yesterday. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazquez at ivazquez.net Wed Jul 27 11:47:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Jul 2005 07:47:49 -0400 Subject: build status In-Reply-To: <20050727133025.717583ea.bugs.michael@gmx.net> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> Message-ID: <1122464869.3550.31.camel@ignacio.lan> On Wed, 2005-07-27 at 13:30 +0200, Michael Schwendt wrote: > All I seem to get is error messages, such as this latest batch, each in a > separate "Prep Error" message: > > could not find path /tmp/102-inkscape-0_42-1_fc5-1122445555/devel/devel for inkscape-0_42-1_fc5. It looks like the buildsys currently parses tobuild as if you're running make build from the rpms CVS module. You get that message when it misparses when you use the devel CVS module. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 bugs.michael at gmx.net Wed Jul 27 12:03:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 14:03:48 +0200 Subject: build status In-Reply-To: <200507270637.43447.dennis@ausil.us> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> <200507270637.43447.dennis@ausil.us> Message-ID: <20050727140348.332bf550.bugs.michael@gmx.net> On Wed, 27 Jul 2005 06:37:35 -0500, Dennis Gilmore wrote: > Once upon a time Wednesday 27 July 2005 6:30 am, Michael Schwendt wrote: > > > > > What would be interesting to learn is what buildsys messages require action > > by the packager. I've yet to see a single success report. Should I have > > received a message for a successful build? > > Yes you get a email stating that the build was successful. That's the theory. In practise, I get only those Prep Error messages. > right now Seth > is going to re-queue failed builds and Dan is going to work on some code > to requeue failed builds automatically. Well that was what was discussed on > irc yesterday. IRC is the wrong place where to mention such details, which are of interest to all Fedora Extras developers. Small updates like this is exactly the stuff that ought to be included in buildsys status update posts. From bugs.michael at gmx.net Wed Jul 27 12:17:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 14:17:37 +0200 Subject: builds started - could not find path /tmp/... In-Reply-To: <20050724132444.3bab85b2.bugs.michael@gmx.net> References: <1122190579.12310.19.camel@cutter> <20050724132444.3bab85b2.bugs.michael@gmx.net> Message-ID: <20050727141737.385b9506.bugs.michael@gmx.net> On Sun, 24 Jul 2005 13:24:44 +0200, Michael Schwendt wrote: > On Sun, 24 Jul 2005 03:36:19 -0400, seth vidal wrote: > > > Hi, > > all of you who have requested builds in the last couple of weeks you > > should start seeing all your builds from the tobuild file pushed through > > the system. > > > > You'll get an email for a success or failure and it should point you to > > build logs of the results. > > > > This should be mostly functional - let us know what breaks. > > Not the slightest idea what this means: > > > Subject: Prep Error (Job 66): sylpheed-2_0_0-0_4_beta6 on development > > could not find path /tmp/66-sylpheed-2_0_0-0_4_beta6-1122190249/devel/devel for sylpheed-2_0_0-0_4_beta6. > This feedback apparently was lost in the list traffic. From bugs.michael at gmx.net Wed Jul 27 12:17:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 14:17:40 +0200 Subject: build status In-Reply-To: <1122464869.3550.31.camel@ignacio.lan> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> <1122464869.3550.31.camel@ignacio.lan> Message-ID: <20050727141740.4b32895a.bugs.michael@gmx.net> On Wed, 27 Jul 2005 07:47:49 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-07-27 at 13:30 +0200, Michael Schwendt wrote: > > All I seem to get is error messages, such as this latest batch, each in a > > separate "Prep Error" message: > > > > could not find path /tmp/102-inkscape-0_42-1_fc5-1122445555/devel/devel for inkscape-0_42-1_fc5. > > It looks like the buildsys currently parses tobuild as if you're running > make build from the rpms CVS module. You get that message when it > misparses when you use the devel CVS module. It looks like that, yes. I've corrected it in the tobuild file. I'm not going to file a bug report about this, since using the tobuild file will likely be obsolete with the new buildsys client. From Jochen at herr-schmitt.de Wed Jul 27 13:58:28 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Jul 2005 15:58:28 +0200 Subject: New Package: pdftk In-Reply-To: <20050727040526.GD19567@redhat.com> References: <20050726190544.GA7573@myhome> <20050727040526.GD19567@redhat.com> Message-ID: <0ML2Dk-1DxmQi0L61-0006s2@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Jul 2005 00:05:26 -0400, you wrote: >This is awesome, BTW! > >Andrew > >[1] >http://www.accesspdf.com/article.php/20041129180128366 They based on this RPMs. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQueTEE9gByurcX4MEQIYAwCgzs/0vz72tND76hEW2zvBtIR4fpQAn0yh mvNX68umhmZdn4o75F/VyrZ/ =Ig2x -----END PGP SIGNATURE----- From rdieter at math.unl.edu Wed Jul 27 14:06:47 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Jul 2005 09:06:47 -0500 Subject: request for review kmymoney2 In-Reply-To: <200507262251.28458.dennis@ausil.us> References: <200507262251.28458.dennis@ausil.us> Message-ID: Dennis Gilmore wrote: > Could someone please review kmymoney2 > > SPEC: http://ausil.us/packages/kmymoney2.spec > SRPM: http://ausil.us/packages/kmymoney2-0.7.4-1.fc4.src.rpm This really builds fine for you on fc4? Build fails for me: http://bugs.kde.org/109342 -- Rex From jspaleta at gmail.com Wed Jul 27 14:27:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jul 2005 10:27:42 -0400 Subject: build status In-Reply-To: <1122446562.3958.12.camel@cutter> References: <1122446562.3958.12.camel@cutter> Message-ID: <604aa7910507270727605994b9@mail.gmail.com> On 7/27/05, seth vidal wrote: > http://buildsys.fedoraproject.org/build-status/ > > If you see one of your jobs has completed successfully then remove it > from the tobuild file, please. > > As soon as I get back up from sleeping for a few hours I'll check on the > latest builds and figure out what failed, or not, as the case may be. > And work on the web page documentation. > > DO NOT EMAIL ME OR CONTACT ME ON IRC WITH PROBLEMS. Email a mailing list > or better yet file a bug. looking at the web interface and the associated output directories... it seems that ppc is holding up the build system. All the items listed as "building" in the web interface have completed the 32 bit and 64 bit pc builds hours ago but they have no ppc output and no status messages associated with ppc building attempts. From naive inspection of the output available for review it seems the ppc build host isnt active at the moment.. but builds are not failing.. that are just stalled in the que. Where do i file a bug? -jef From skvidal at phy.duke.edu Wed Jul 27 14:36:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 10:36:07 -0400 Subject: build status In-Reply-To: <604aa7910507270727605994b9@mail.gmail.com> References: <1122446562.3958.12.camel@cutter> <604aa7910507270727605994b9@mail.gmail.com> Message-ID: <1122474968.7082.7.camel@cutter> > looking at the web interface and the associated output directories... > it seems that ppc is holding up the build system. All the items listed > as "building" in the web interface have completed the 32 bit and 64 > bit pc builds hours ago but they have no ppc output and no status > messages associated with ppc building attempts. From naive inspection > of the output available for review it seems the ppc build host isnt > active at the moment.. but builds are not failing.. that are just > stalled in the que. > right now it's not stalled but the ppc builds take longer b/c of where the machine is. There was a problem with a network timeout to the machine early this morning but I recovered that error. > Where do i file a bug? > there's this neat new system - it's called bugzilla. :) -sv From dennis at ausil.us Wed Jul 27 14:33:40 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 27 Jul 2005 09:33:40 -0500 (CDT) Subject: request for review kmymoney2 In-Reply-To: References: <200507262251.28458.dennis@ausil.us> Message-ID: <49465.68.254.239.135.1122474820.squirrel@www.ausil.us> > Dennis Gilmore wrote: > >> Could someone please review kmymoney2 >> >> SPEC: http://ausil.us/packages/kmymoney2.spec >> SRPM: http://ausil.us/packages/kmymoney2-0.7.4-1.fc4.src.rpm > > This really builds fine for you on fc4? Build fails for me: > http://bugs.kde.org/109342 > Yep sure does. built it via rpmbuild and mock Dennis From Jochen at herr-schmitt.de Wed Jul 27 14:54:32 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Jul 2005 16:54:32 +0200 Subject: New Package: pdftk In-Reply-To: <1122464452.3550.26.camel@ignacio.lan> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> Message-ID: <0ML2Dk-1DxnJ41V7X-0002wj@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Jul 2005 07:40:52 -0400, you wrote: >? What about dist rights of the contents of >java_libs/com/lowagie/text/pdf/fonts? I have toke a look into this directory. I found several afm files, which contains a copyright comment from Adobe System Inc. So I have wrote a mail to the upstream author to verify this situation. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQuegO09gByurcX4MEQIdEACdEVIpp80fEWW9Cm3cb/4ftNUqjlwAnj7K dpxGBvtwl/dscxHwYW4M5p2x =6yKP -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Wed Jul 27 15:02:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 11:02:43 -0400 Subject: build status In-Reply-To: <20050727073651.GG2601@salstar.sk> References: <1122446562.3958.12.camel@cutter> <20050727073651.GG2601@salstar.sk> Message-ID: <1122476563.7082.16.camel@cutter> > But can anybody tell me, why "galeon" is still not built for extras4? > There are dependency problems with latest Mozilla from fedora core > updates and galeon. Users can't update to latest Mozilla+Galeon > for these problems. b/c the galeon package has a problem in its spec file - I filed a bug on it. > There are also problems with latest updates for fedora extras 4: > Error: Missing Dependency: libcddb.so.0 is needed by package libcdio > There is a new libcddb release which breaks compatibility and there > is not new libcdio. > > I see, that libcdio is now built for development, but not for a stable > release. Why you are building packages for development and not fixing > dependency problems for stable releases? :( look at the failed builds. libcdio failed to build for fe4. > What are "JOB ID's" on build-status page? Galeon has ID 2 and other > packages are built, but this stable still not (I am watching build > status only aprox. a hour). job ids are just an arbitrary number assigned to the build job. most of the jobs that are building are waiting on the ppc build box to become un-busy. -sv From skvidal at phy.duke.edu Wed Jul 27 15:04:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 11:04:35 -0400 Subject: build status In-Reply-To: <200507270637.43447.dennis@ausil.us> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> <200507270637.43447.dennis@ausil.us> Message-ID: <1122476675.7082.19.camel@cutter> On Wed, 2005-07-27 at 06:37 -0500, Dennis Gilmore wrote: > Once upon a time Wednesday 27 July 2005 6:30 am, Michael Schwendt wrote: > > > > > What would be interesting to learn is what buildsys messages require action > > by the packager. I've yet to see a single success report. Should I have > > received a message for a successful build? > Yes you get a email stating that the build was successful. right now Seth > is going to re-queue failed builds and Dan is going to work on some code > to requeue failed builds automatically. Well that was what was discussed on > irc yesterday. > well I'm going to requeue failed builds that failed for repository reasons or for other build-system-related reasons. if a build failed b/c someone didn't upload a tarball I'm not requeuing it. :) -sv From skvidal at phy.duke.edu Wed Jul 27 15:05:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 11:05:13 -0400 Subject: build status In-Reply-To: <1122464869.3550.31.camel@ignacio.lan> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> <1122464869.3550.31.camel@ignacio.lan> Message-ID: <1122476713.7082.21.camel@cutter> On Wed, 2005-07-27 at 07:47 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-07-27 at 13:30 +0200, Michael Schwendt wrote: > > All I seem to get is error messages, such as this latest batch, each in a > > separate "Prep Error" message: > > > > could not find path /tmp/102-inkscape-0_42-1_fc5-1122445555/devel/devel for inkscape-0_42-1_fc5. > > It looks like the buildsys currently parses tobuild as if you're running > make build from the rpms CVS module. You get that message when it > misparses when you use the devel CVS module. > hmm - looks like a problem in my regex that I wrote to import from tobuild to the buildsys - I'll check that out. thanks -sv From bugs.michael at gmx.net Wed Jul 27 15:12:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Jul 2005 17:12:06 +0200 Subject: build status In-Reply-To: <1122476563.7082.16.camel@cutter> References: <1122446562.3958.12.camel@cutter> <20050727073651.GG2601@salstar.sk> <1122476563.7082.16.camel@cutter> Message-ID: <20050727171206.0e2ae4dd.bugs.michael@gmx.net> On Wed, 27 Jul 2005 11:02:43 -0400, seth vidal wrote: > > There are also problems with latest updates for fedora extras 4: > > Error: Missing Dependency: libcddb.so.0 is needed by package libcdio > > There is a new libcddb release which breaks compatibility and there > > is not new libcdio. > > > > I see, that libcdio is now built for development, but not for a stable > > release. Why you are building packages for development and not fixing > > dependency problems for stable releases? :( > > look at the failed builds. libcdio failed to build for fe4. This is expected. I explained this on FESCO list and proposed a work-around, which requires somebody with the proper privileges to execute the task. From Jochen at herr-schmitt.de Wed Jul 27 15:12:43 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Jul 2005 17:12:43 +0200 Subject: New Package: pdftk In-Reply-To: <1122464452.3550.26.camel@ignacio.lan> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> Message-ID: <0MKwpI-1DxnaQ1DeE-00013t@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Jul 2005 07:40:52 -0400, you wrote: >? What about dist rights of the contents of >java_libs/com/lowagie/text/pdf/fonts? I have got a look to debian. In debian you my find pdftk in the main brunch. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQuekbE9gByurcX4MEQL7uQCfYr3Gevl4PXvz9xPMphEvUCoQWOkAnA0F GNTTQ2ypOg0Omjjal7+NLNON =n7qY -----END PGP SIGNATURE----- From alex at dalloz.de Wed Jul 27 15:20:56 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Wed, 27 Jul 2005 17:20:56 +0200 Subject: Request for review: keychain opt-in mechanism In-Reply-To: <1121877978.6862.174.camel@serendipity.dogma.lan> References: <1121877978.6862.174.camel@serendipity.dogma.lan> Message-ID: <1122477656.3683.15.camel@serendipity.dogma.lan> Am Mi, den 20.07.2005 schrieb Alexander Dalloz um 18:46: > Starting a new thread about keychain and especially the requested opt-in > mechanism I like to request reviewing my fresh new script suggestion. > The old thread is to be found as > > https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00593.html > > I am starting with a fresh new thread to focus on what the past > discussion brought up to be helpful within the package. > > Ed Hill thankfully approved my presented keychain src.rpm on 13th - now > as some of you (namely Chip Turner, Ed Hill, Ville Skytt?) voted for an > ease of use mechanism I beg for criticising following: [ ... ] > Alexander Ok, hope to get the keychain package pushed up into Extras and from my work queue by this to be hopefully the last request for a review. The package / tool is very small and as there was already a review and approval I just desire mainly a critical view over the opt-in mechanism / profile.d scripts. http://www.uni-x.org/review/keychain.spec http://www.uni-x.org/review/keychain-2.5.4.1-2.src.rpm The profile scripts should work for all shell types Fedora ships with (bash, sh, csh, tcsh, ksh, zsh). Whoever sees a problem please report it. Very short comment: I do not use the %{?dist} tag as the rpm just wraps 3 shell scripts and is in no way distribution release specific. Regards Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Wed Jul 27 15:27:16 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jul 2005 11:27:16 -0400 Subject: build status In-Reply-To: <1122474968.7082.7.camel@cutter> References: <1122446562.3958.12.camel@cutter> <604aa7910507270727605994b9@mail.gmail.com> <1122474968.7082.7.camel@cutter> Message-ID: <604aa791050727082753d927dc@mail.gmail.com> > > Where do i file a bug? > > > > there's this neat new system - it's called bugzilla. :) bugzilla.... inconceivable! But where exactly? I've only had one cup of coffee today.. so it wasn't exactly obvious which product/component I'm suppose to file against. For the record if anyone else needs to file a about the build system: bugzilla.redhat.com Product: Fedora Infrastructure Component: extras buildsys -jef From qspencer at ieee.org Wed Jul 27 16:05:55 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 27 Jul 2005 11:05:55 -0500 Subject: build status In-Reply-To: <1122476675.7082.19.camel@cutter> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> <200507270637.43447.dennis@ausil.us> <1122476675.7082.19.camel@cutter> Message-ID: <42E7B0E3.6010901@ieee.org> seth vidal wrote: >On Wed, 2005-07-27 at 06:37 -0500, Dennis Gilmore wrote: > > >>Once upon a time Wednesday 27 July 2005 6:30 am, Michael Schwendt wrote: >> >> >> >>>What would be interesting to learn is what buildsys messages require action >>>by the packager. I've yet to see a single success report. Should I have >>>received a message for a successful build? >>> >>> >>Yes you get a email stating that the build was successful. right now Seth >>is going to re-queue failed builds and Dan is going to work on some code >>to requeue failed builds automatically. Well that was what was discussed on >>irc yesterday. >> >> >> > >well I'm going to requeue failed builds that failed for repository >reasons or for other build-system-related reasons. > >if a build failed b/c someone didn't upload a tarball I'm not requeuing >it. :) > > > There have been hints that the tobuild file is on its way out. Until then, what if my build failed because of a mistake in the spec file? I fixed the spec, bumped the version, and re-requested the build. Should I remove the old one from the tobuild file to avoid it being re-queued, or will that happen automatically if there's a new one (like the old build system did)? -Quentin From rdieter at math.unl.edu Wed Jul 27 16:29:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Jul 2005 11:29:28 -0500 Subject: request for review kmymoney2 In-Reply-To: <49465.68.254.239.135.1122474820.squirrel@www.ausil.us> References: <200507262251.28458.dennis@ausil.us> <49465.68.254.239.135.1122474820.squirrel@www.ausil.us> Message-ID: Dennis Gilmore wrote: >>Dennis Gilmore wrote: >> >> >>>Could someone please review kmymoney2 >>> >>>SPEC: http://ausil.us/packages/kmymoney2.spec >>>SRPM: http://ausil.us/packages/kmymoney2-0.7.4-1.fc4.src.rpm >> >>This really builds fine for you on fc4? Build fails for me: >>http://bugs.kde.org/109342 >> > > Yep sure does. built it via rpmbuild and mock Ah, I bet that's because Fedora's KDE packages (incorrectly) set in /usr/include/kde/kdemacros.h: #define __KDE_HAVE_GCC_VISIBILITY 0 instead of /* #undef __KDE_HAVE_GCC_VISIBILITY */ or #undef __KDE_HAVE_GCC_VISIBILITY -- Rex From dennis at ausil.us Wed Jul 27 16:45:31 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 27 Jul 2005 11:45:31 -0500 Subject: request for review kmymoney2 In-Reply-To: References: <200507262251.28458.dennis@ausil.us> <49465.68.254.239.135.1122474820.squirrel@www.ausil.us> Message-ID: <200507271145.36586.dennis@ausil.us> Once upon a time Wednesday 27 July 2005 11:29 am, Rex Dieter wrote: > Dennis Gilmore wrote: > >>Dennis Gilmore wrote: > >>>Could someone please review kmymoney2 > >>> > >>>SPEC: http://ausil.us/packages/kmymoney2.spec > >>>SRPM: http://ausil.us/packages/kmymoney2-0.7.4-1.fc4.src.rpm > >> > >>This really builds fine for you on fc4? Build fails for me: > >>http://bugs.kde.org/109342 > > > > Yep sure does. built it via rpmbuild and mock > > Ah, I bet that's because Fedora's KDE packages (incorrectly) set in > /usr/include/kde/kdemacros.h: > > #define __KDE_HAVE_GCC_VISIBILITY 0 > > instead of > > /* #undef __KDE_HAVE_GCC_VISIBILITY */ > or > #undef __KDE_HAVE_GCC_VISIBILITY > > -- Rex could be why. i tried a build on FC3 x86_64 and it failed similiar to your bug report. or perhaps it due to gcc4 as opposed to gcc3.4. I did patch configue not to check for gcc blacklisting. -- Dennis Gilmore RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Jochen at herr-schmitt.de Wed Jul 27 17:32:41 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Jul 2005 19:32:41 +0200 Subject: New Package: pdftk In-Reply-To: <0ML2Dk-1DxnJ41V7X-0002wj@mrelayeu.kundenserver.de> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> <0ML2Dk-1DxnJ41V7X-0002wj@mrelayeu.kundenserver.de> Message-ID: <0MKwpI-1Dxpm12Mgf-0002wQ@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Jul 2005 16:54:32 +0200, you wrote: >I have toke a look into this directory. I found several afm >files, which contains a copyright comment from Adobe System Inc. >So I have wrote a mail to the upstream author to verify this >situation. Here the answer of the upstram author: Hello- I believe they are free distributable. I couldn't find the license at Adobe.com, but this appears to be a copy of it: http://multivalent.sourceforge.net/License-Adobe.txt Linked from: http://multivalent.sourceforge.net/license.html Namely: This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification, provided that all copyright notices are retained; that the AFM files are not distributed without this file; that all modifications to this file or any of the AFM files are prominently noted in the modified file(s); and that this paragraph is not modified. Adobe Systems has no responsibility or obligation to support the use of the AFM files. HTH- I hope this will be ok. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQufFRE9gByurcX4MEQL6OACff0ks/3jbHc5rKLPRx47fXsNJY3gAn2YK f3mKXVzarJUMMv2N9FxMerVc =lk7o -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Wed Jul 27 17:42:58 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 27 Jul 2005 19:42:58 +0200 Subject: New Package: pdftk In-Reply-To: <0MKwpI-1Dxpm12Mgf-0002wQ@mrelayeu.kundenserver.de> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> <0ML2Dk-1DxnJ41V7X-0002wj@mrelayeu.kundenserver.de> <0MKwpI-1Dxpm12Mgf-0002wQ@mrelayeu.kundenserver.de> Message-ID: <1122486178.32580.16.camel@rousalka.dyndns.org> Le mercredi 27 juillet 2005 ? 19:32 +0200, Jochen Schmitt a ?crit : > On Wed, 27 Jul 2005 16:54:32 +0200, you wrote: > > >I have toke a look into this directory. I found several afm > >files, which contains a copyright comment from Adobe System Inc. > >So I have wrote a mail to the upstream author to verify this > >situation. Can't the urw fonts be used instead ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Wed Jul 27 17:51:46 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Jul 2005 19:51:46 +0200 Subject: New Package: pdftk In-Reply-To: <1122464452.3550.26.camel@ignacio.lan> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> Message-ID: <0MKwh2-1Dxq4R1tuV-0003DJ@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Jul 2005 07:40:52 -0400, you wrote: >* PGP Signed by an unverified key: 07/27/05 at 13:40:52 >On Tue, 2005-07-26 at 21:05 +0200, Jochen Schmitt wrote: >> SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-1-src.rpm >> SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec > >- Don't need to compress man pages >- Don't need pdftk.1.notes >- No copy of GPL included >- Don't need explicit Requires of libgcj >+ Builds in mock >? What about dist rights of the contents of >java_libs/com/lowagie/text/pdf/fonts? I have uploaded a corrected version: SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-2-src.rpm SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQufJuk9gByurcX4MEQLkagCffFaAo4XdBYkpVwleyEUpEqcvWZUAn0GW Fij6bNZvxp6DUvvsPvkBcgcS =cR7s -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Wed Jul 27 18:27:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 14:27:00 -0400 Subject: build status In-Reply-To: <42E7B0E3.6010901@ieee.org> References: <1122446562.3958.12.camel@cutter> <20050727133025.717583ea.bugs.michael@gmx.net> <200507270637.43447.dennis@ausil.us> <1122476675.7082.19.camel@cutter> <42E7B0E3.6010901@ieee.org> Message-ID: <1122488821.7082.29.camel@cutter> On Wed, 2005-07-27 at 11:05 -0500, Quentin Spencer wrote: > seth vidal wrote: > > >On Wed, 2005-07-27 at 06:37 -0500, Dennis Gilmore wrote: > > > > > >>Once upon a time Wednesday 27 July 2005 6:30 am, Michael Schwendt wrote: > >> > >> > >> > >>>What would be interesting to learn is what buildsys messages require action > >>>by the packager. I've yet to see a single success report. Should I have > >>>received a message for a successful build? > >>> > >>> > >>Yes you get a email stating that the build was successful. right now Seth > >>is going to re-queue failed builds and Dan is going to work on some code > >>to requeue failed builds automatically. Well that was what was discussed on > >>irc yesterday. > >> > >> > >> > > > >well I'm going to requeue failed builds that failed for repository > >reasons or for other build-system-related reasons. > > > >if a build failed b/c someone didn't upload a tarball I'm not requeuing > >it. :) > > > > > > > > There have been hints that the tobuild file is on its way out. Until > then, what if my build failed because of a mistake in the spec file? I > fixed the spec, bumped the version, and re-requested the build. Should I > remove the old one from the tobuild file to avoid it being re-queued, or > will that happen automatically if there's a new one (like the old build > system did)? > remove the old one, yes. always remove broken items from the tobuild file also remove successful ones. -sv From buildsys at fedoraproject.org Wed Jul 27 18:33:01 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jul 2005 14:33:01 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050727183301.D06417FE5@extras64> Packages built and released for Fedora Extras development: 3 apel-10.6-8.fc5 cdlabelgen-3.5.0-1.fc5 fedora-rpmdevtools-1.1-1.fc5 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 Wed Jul 27 18:33:11 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jul 2005 14:33:11 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050727183311.D2C847FE5@extras64> Packages built and released for Fedora Extras 4: 2 cdlabelgen-3.5.0-1.fc4 fedora-rpmdevtools-1.1-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From sopwith at redhat.com Wed Jul 27 18:51:05 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 27 Jul 2005 14:51:05 -0400 (EDT) Subject: Also about my Fedora account In-Reply-To: References: Message-ID: On Tue, 26 Jul 2005, Zing wrote: > About how long does it take for the cla to clear? > > I've emailed and faxed my cla last week sometime and I attempted to add > myself to the cvsextras group, but I get the following: > > 'Add' action denied. You may need to become a member of the cla_done > group first. > > Is there some step I'm missing, or should i sit tight and wait? You need to complete the CLA (contributor's license agreement) before joining cvsextras. There is no faxing submission CLAs since this spring - the process is basically to click on the link in the account system, then follow the instructions in the e-mail that you get. Best, -- Elliot From sopwith at redhat.com Wed Jul 27 18:52:04 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 27 Jul 2005 14:52:04 -0400 (EDT) Subject: Fedora account In-Reply-To: <1122435491.16419.11.camel@pc7.dolda2000.com> References: <1122426121.16419.2.camel@pc7.dolda2000.com> <20050727043856.7b255970.bugs.michael@gmx.net> <1122432302.16419.7.camel@pc7.dolda2000.com> <20050727051220.43cb7fcb.bugs.michael@gmx.net> <1122435491.16419.11.camel@pc7.dolda2000.com> Message-ID: On Wed, 27 Jul 2005, Fredrik Tolf wrote: > Indeed. I tried the "Edit your account" link, and indeed I could log in, > and I'd say it seems as though my account is approved and functional, > which I find strange since I have received no notification of approval > (and yes, I doublechecked the e-mail address I had given right now). > > Was I not supposed to get a notification that I had been approved? Your account exists the moment you create it, but you need to do more than simply create an account in order to get commit access for extras. Please follow the remaining steps listed on the main account system page... -- Elliot From skvidal at phy.duke.edu Wed Jul 27 19:45:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 27 Jul 2005 15:45:56 -0400 Subject: build status part deux Message-ID: <1122493556.7082.44.camel@cutter> We got all the fc3 builds finished and done. Rawhide is a bit unusuable right now so I'm deferring development builds and we're trying to get all the fc4 builds done. We've been having a bit of trouble with the ppc builds box and we're trying to figure out why it is flaking out. -sv From ivazquez at ivazquez.net Wed Jul 27 22:03:43 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Jul 2005 18:03:43 -0400 Subject: New Package: pdftk In-Reply-To: <0MKwpI-1Dxpm12Mgf-0002wQ@mrelayeu.kundenserver.de> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> <0ML2Dk-1DxnJ41V7X-0002wj@mrelayeu.kundenserver.de> <0MKwpI-1Dxpm12Mgf-0002wQ@mrelayeu.kundenserver.de> Message-ID: <1122501823.3550.33.camel@ignacio.lan> On Wed, 2005-07-27 at 19:32 +0200, Jochen Schmitt wrote: > This file and the 14 PostScript(R) AFM files it accompanies may > be > used, copied, and distributed for any purpose and without charge, > with > or without modification, provided that all copyright notices are > retained; that the AFM files are not distributed without this > file; > that all modifications to this file or any of the AFM files are > prominently noted in the modified file(s); and that this > paragraph is > not modified. Adobe Systems has no responsibility or obligation > to > support the use of the AFM files. If this file isn't included with it then the .afm files can't be redistributed. Please ask upstream to remedy this situation. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ivazquez at ivazquez.net Wed Jul 27 22:08:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Jul 2005 18:08:02 -0400 Subject: New Package: pdftk In-Reply-To: <0MKwh2-1Dxq4R1tuV-0003DJ@mrelayeu.kundenserver.de> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> <0MKwh2-1Dxq4R1tuV-0003DJ@mrelayeu.kundenserver.de> Message-ID: <1122502082.3550.35.camel@ignacio.lan> On Wed, 2005-07-27 at 19:51 +0200, Jochen Schmitt wrote: > SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-2-src.rpm > SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec Unfortunately including debian/copyright doesn't work as it doesn't contain a copy of the literal text of the GPL. Please find a copy from another source and include it as Source1. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 katzj at redhat.com Wed Jul 27 22:32:53 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Jul 2005 18:32:53 -0400 Subject: build status part deux In-Reply-To: <1122493556.7082.44.camel@cutter> References: <1122493556.7082.44.camel@cutter> Message-ID: <1122503573.5406.8.camel@bree.local.net> On Wed, 2005-07-27 at 15:45 -0400, seth vidal wrote: > We got all the fc3 builds finished and done. > Rawhide is a bit unusuable right now so I'm deferring development builds > and we're trying to get all the fc4 builds done. We've been having a bit > of trouble with the ppc builds box and we're trying to figure out why it > is flaking out. And it looks like we now have working ppc builds. Going from a 32bit ppc box to a 64bit ppc box involved working through some not entirely obvious at first problems, but those are looking to be pretty happy now. I'll check back on things once I get home to make sure things are continuing to go happily and to start working towards bringing up the other build machines. Jeremy From buildsys at fedoraproject.org Wed Jul 27 22:54:30 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jul 2005 18:54:30 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050727225430.18BA88200@extras64> Packages built and released for Fedora Extras 4: 7 gif2png-2.5.1-1.fc4 icmpdn-0.3-2 ip-sentinel-0.12-5.fc4 libcddb-1.2.0-1.fc4 libstatgrab-0.11.1-3.fc4 mod_suphp-0.5.2-8.fc4 scim-anthy-0.5.1-2.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From paul at all-the-johnsons.co.uk Wed Jul 27 23:13:42 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 28 Jul 2005 00:13:42 +0100 Subject: Dependancy probs Message-ID: <1122506022.28015.9.camel@localhost> Hi, With the latest builds from the main rawhide and the extras, I'm getting the following dep. errors. Repository development already added, not adding again Repository extras already added, not adding again Repository base already added, not adding again Error: Missing Dependency: libcdio.so.5 is needed by package libcddb Error: Missing Dependency: httpd = 1:2.0.54-11 is needed by package mod_ssl Error: Missing Dependency: libcdio.so.5 is needed by package vcdimager Error: Missing Dependency: popt = 1.10.1 is needed by package rpm Error: Missing Dependency: libpcap.so.0.9.1 is needed by package ethereal Error: Missing Dependency: libpcap.so.0.9.1 is needed by package ethereal-gnome Error: Missing Dependency: libcdio.so.5(CDIO_5) is needed by package vcdimager Error: Missing Dependency: libcdio.so.5(CDIO_5) is needed by package libcddb TTFN Paul -- "Some people will do anything for a woman in uniform" - The Doctor - Unregenerate (Big Finish audio) -------------- 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 bugs.michael at gmx.net Wed Jul 27 23:19:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Jul 2005 01:19:30 +0200 Subject: Dependancy probs In-Reply-To: <1122506022.28015.9.camel@localhost> References: <1122506022.28015.9.camel@localhost> Message-ID: <20050728011930.01488102.bugs.michael@gmx.net> On Thu, 28 Jul 2005 00:13:42 +0100, Paul wrote: > Hi, > > With the latest builds from the main rawhide and the extras, I'm getting > the following dep. errors. > > Repository development already added, not adding again > Repository extras already added, not adding again > Repository base already added, not adding again > Error: Missing Dependency: libcdio.so.5 is needed by package libcddb > Error: Missing Dependency: httpd = 1:2.0.54-11 is needed by package > mod_ssl > Error: Missing Dependency: libcdio.so.5 is needed by package vcdimager > Error: Missing Dependency: popt = 1.10.1 is needed by package rpm > Error: Missing Dependency: libpcap.so.0.9.1 is needed by package > ethereal > Error: Missing Dependency: libpcap.so.0.9.1 is needed by package > ethereal-gnome > Error: Missing Dependency: libcdio.so.5(CDIO_5) is needed by package > vcdimager > Error: Missing Dependency: libcdio.so.5(CDIO_5) is needed by package > libcddb > > TTFN > > Paul Known issue. https://bugzilla.redhat.com/164270 From andreas.bierfert at lowlatency.de Wed Jul 27 23:35:30 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 28 Jul 2005 01:35:30 +0200 Subject: Request for review: koffice In-Reply-To: References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> <42E0D984.4050401@redhat.com> Message-ID: <42E81A42.7020702@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rex Dieter wrote: >> I suspect neither Obsoletes nor Conflicts are needed in -core. > > > IMO, -core needs a Conflicts because it really does own files that will > conflict with the older koffice. Hm I will test it this weekend. I'm stuck with a project from university till Friday. Sorry for the delay. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC6BpCQEQyPsWM8csRAujxAJ0QEK52D2ObJmCPt8L/oFYtlcZX6QCeMKkB diyJuQrqU6lX7V7xjmrdCs0= =nkR/ -----END PGP SIGNATURE----- From gdk at redhat.com Wed Jul 27 23:50:52 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Jul 2005 19:50:52 -0400 (EDT) Subject: build status part deux In-Reply-To: <1122503573.5406.8.camel@bree.local.net> References: <1122493556.7082.44.camel@cutter> <1122503573.5406.8.camel@bree.local.net> Message-ID: /me applauds! Well done to everyone putting in the work to fix this. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Wed, 27 Jul 2005, Jeremy Katz wrote: > On Wed, 2005-07-27 at 15:45 -0400, seth vidal wrote: > > We got all the fc3 builds finished and done. > > Rawhide is a bit unusuable right now so I'm deferring development builds > > and we're trying to get all the fc4 builds done. We've been having a bit > > of trouble with the ppc builds box and we're trying to figure out why it > > is flaking out. > > And it looks like we now have working ppc builds. Going from a 32bit > ppc box to a 64bit ppc box involved working through some not entirely > obvious at first problems, but those are looking to be pretty happy > now. > > I'll check back on things once I get home to make sure things are > continuing to go happily and to start working towards bringing up the > other build machines. > > Jeremy > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From ed at eh3.com Thu Jul 28 00:30:42 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 27 Jul 2005 20:30:42 -0400 Subject: FE account system -- offline for now? Message-ID: <1122510643.7905.322.camel@ernie> Hi folks, I just searched though bugzilla.redhat.com and could find no place to file this "bug" so please be patient with me while I email the list. Today, I pointed a new potential packager at: http://fedoraproject.org/wiki/Extras/Contributors and, apparently, its been unavailable all day today. What happened? Will it be back anytime soon? thanks, Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From jspaleta at gmail.com Thu Jul 28 00:31:57 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jul 2005 20:31:57 -0400 Subject: Any tips or guidelines for creating ruby packages? Message-ID: <604aa791050727173121bee18d@mail.gmail.com> Are there expert opinions on special considerations when packaging ruby based software as rpms? The wiki packagenaming guideline is utterly silent on the isue of ruby. -jef From jspaleta at gmail.com Thu Jul 28 00:33:25 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jul 2005 20:33:25 -0400 Subject: FE account system -- offline for now? In-Reply-To: <1122510643.7905.322.camel@ernie> References: <1122510643.7905.322.camel@ernie> Message-ID: <604aa79105072717335dcd3ab6@mail.gmail.com> On 7/27/05, Ed Hill wrote: > > Hi folks, > > I just searched though bugzilla.redhat.com and could find no place to > file this "bug" so please be patient with me while I email the list. Product: Fedora Infrastructure Component: Account System https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Infrastructure -jef From ed at eh3.com Thu Jul 28 00:47:28 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 27 Jul 2005 20:47:28 -0400 Subject: FE account system -- offline for now? In-Reply-To: <604aa79105072717335dcd3ab6@mail.gmail.com> References: <1122510643.7905.322.camel@ernie> <604aa79105072717335dcd3ab6@mail.gmail.com> Message-ID: <1122511648.7905.325.camel@ernie> On Wed, 2005-07-27 at 20:33 -0400, Jeff Spaleta wrote: > On 7/27/05, Ed Hill wrote: > > > > I just searched though bugzilla.redhat.com and could find no place to > > file this "bug" so please be patient with me while I email the list. > > Product: Fedora Infrastructure > Component: Account System Thank you, Jef! And heres the URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164463 Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From tcallawa at redhat.com Thu Jul 28 00:51:30 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 19:51:30 -0500 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa791050727173121bee18d@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> Message-ID: <1122511890.2645.11.camel@localhost.localdomain> On Wed, 2005-07-27 at 20:31 -0400, Jeff Spaleta wrote: > Are there expert opinions on special considerations when packaging > ruby based software as rpms? The wiki packagenaming guideline is > utterly silent on the isue of ruby. Treat ruby like perl. If it adds functionality to ruby, then it needs to be in the ruby namespace (ruby-foo), unless it has ruby in its name already. If its an application written in ruby, then it doesn't need to be in the namespace (foo). ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jspaleta at gmail.com Thu Jul 28 01:00:16 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jul 2005 21:00:16 -0400 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <1122511890.2645.11.camel@localhost.localdomain> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> Message-ID: <604aa7910507271800533887d8@mail.gmail.com> On 7/27/05, Tom 'spot' Callaway wrote: > Treat ruby like perl. If it adds functionality to ruby, then it needs to > be in the ruby namespace (ruby-foo), unless it has ruby in its name > already. If its an application written in ruby, then it doesn't need to > be in the namespace (foo). For functionality enhancing packages.. do I use perl packaging like provides/requires syntax? -jef From tcallawa at redhat.com Thu Jul 28 01:06:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 20:06:45 -0500 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa7910507271800533887d8@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> Message-ID: <1122512805.2645.14.camel@localhost.localdomain> On Wed, 2005-07-27 at 21:00 -0400, Jeff Spaleta wrote: > On 7/27/05, Tom 'spot' Callaway wrote: > > Treat ruby like perl. If it adds functionality to ruby, then it needs to > > be in the ruby namespace (ruby-foo), unless it has ruby in its name > > already. If its an application written in ruby, then it doesn't need to > > be in the namespace (foo). > > For functionality enhancing packages.. do I use perl packaging like > provides/requires syntax? Well, I don't think rpm understands ruby(function), and there are no pre-existant macros that I'm aware of. But otherwise, the perl model should be sufficient. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jspaleta at gmail.com Thu Jul 28 01:52:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jul 2005 21:52:07 -0400 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <1122512805.2645.14.camel@localhost.localdomain> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> Message-ID: <604aa79105072718525d0617a4@mail.gmail.com> On 7/27/05, Tom 'spot' Callaway wrote: > Well, I don't think rpm understands ruby(function), and there are no > pre-existant macros that I'm aware of. But otherwise, the perl model > should be sufficient. Sounds to me like there's a lot of discussion that needs to be done.. before anyone could make a legit stab at getting ruby-gnome2 packaged up as a set of packages to be used as a dependencies for applications like alexandria. the ruby-gnome2 tarball builds pretty easily but I'd hate to make arbitrary packaging choices when trying to split that up into packages that gets enshrined as policy. -jef"Curses notting for telling him about alexandria.. and is kicking himself for showing his wife alexandria which is now her most used application"spaleta From tcallawa at redhat.com Thu Jul 28 01:57:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 20:57:50 -0500 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa79105072718525d0617a4@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> Message-ID: <1122515871.2645.16.camel@localhost.localdomain> On Wed, 2005-07-27 at 21:52 -0400, Jeff Spaleta wrote: > On 7/27/05, Tom 'spot' Callaway wrote: > > Well, I don't think rpm understands ruby(function), and there are no > > pre-existant macros that I'm aware of. But otherwise, the perl model > > should be sufficient. > > Sounds to me like there's a lot of discussion that needs to be done.. > before anyone could make a legit stab at getting ruby-gnome2 packaged > up as a set of packages to be used as a dependencies for applications > like alexandria. > > the ruby-gnome2 tarball builds pretty easily but I'd hate to make > arbitrary packaging choices when trying to split that up into packages > that gets enshrined as policy. Package it up, and I'll look it over. If we need to make packaging policy changes, I'll help. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Thu Jul 28 02:17:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 21:17:41 -0500 Subject: Request for review: alleyoop Message-ID: <1122517062.2645.21.camel@localhost.localdomain> Alleyoop is a graphical front-end to the increasingly popular Valgrind memory checker for x86 GNU/ Linux using the Gtk+ widget set and other GNOME libraries for the X-Windows environment. Small, and simple. Tested on x86 (FC4). SRPM: http://www.auroralinux.org/people/spot/review/alleyoop-0.9.0-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/alleyoop.spec Please review, thanks in advance. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From wtogami at redhat.com Thu Jul 28 02:36:41 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 27 Jul 2005 16:36:41 -1000 Subject: Request for review: alleyoop In-Reply-To: <1122517062.2645.21.camel@localhost.localdomain> References: <1122517062.2645.21.camel@localhost.localdomain> Message-ID: <42E844B9.3040003@redhat.com> Tom 'spot' Callaway wrote: > Alleyoop is a graphical front-end to the increasingly popular Valgrind > memory checker for x86 GNU/ Linux using the Gtk+ widget set and other > GNOME libraries for the X-Windows environment. > > Small, and simple. Tested on x86 (FC4). > > SRPM: > http://www.auroralinux.org/people/spot/review/alleyoop-0.9.0-1.src.rpm > SPEC: http://www.auroralinux.org/people/spot/review/alleyoop.spec > ExclusiveArch: x86 x86_64 Is 'x86' a valid arch? Usually you see the macro that expands to all of the ix86 archs. I can't remember what that is arch off hand. Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Thu Jul 28 02:41:53 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Jul 2005 22:41:53 -0400 Subject: Request for review: alleyoop In-Reply-To: <42E844B9.3040003@redhat.com> References: <1122517062.2645.21.camel@localhost.localdomain> <42E844B9.3040003@redhat.com> Message-ID: <1122518514.4206.0.camel@ignacio.lan> On Wed, 2005-07-27 at 16:36 -1000, Warren Togami wrote: > Tom 'spot' Callaway wrote: > > Alleyoop is a graphical front-end to the increasingly popular Valgrind > > memory checker for x86 GNU/ Linux using the Gtk+ widget set and other > > GNOME libraries for the X-Windows environment. > > > > Small, and simple. Tested on x86 (FC4). > > > > SRPM: > > http://www.auroralinux.org/people/spot/review/alleyoop-0.9.0-1.src.rpm > > SPEC: http://www.auroralinux.org/people/spot/review/alleyoop.spec > > > > ExclusiveArch: x86 x86_64 > Is 'x86' a valid arch? Usually you see the macro that expands to all of > the ix86 archs. I can't remember what that is arch off hand. %{ix86} -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Thu Jul 28 03:46:35 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 22:46:35 -0500 Subject: Review: perl-CGI-Simple In-Reply-To: <42D2BE75.5010207@di.uminho.pt> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2BE75.5010207@di.uminho.pt> Message-ID: <1122522395.2645.25.camel@localhost.localdomain> On Mon, 2005-07-11 at 19:46 +0100, Jos? Pedro Oliveira wrote: > Tom, > > > perl-CGI-Simple: > > Simple totally OO CGI interface that is CGI.pm compliant > > Needswork: > * wrong URL (case-sensitive) > * wrong permissions in *.pm and doc files (+x ?) > * one documentation files missing (cgi-simple_vs_cgi-pm.html) > (the other html files in the htnl directory are the man pages) All of these items are fixed in -3: SRPM: http://www.auroralinux.org/people/spot/review/Maypole/perl-CGI-Simple-0.077-3.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/Maypole/perl-CGI-Simple.spec Please re-review or approve. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Thu Jul 28 03:51:49 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 22:51:49 -0500 Subject: Review: perl-Exporter-Lite In-Reply-To: <42D2C266.6080202@di.uminho.pt> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2C266.6080202@di.uminho.pt> Message-ID: <1122522709.2645.30.camel@localhost.localdomain> On Mon, 2005-07-11 at 20:03 +0100, Jos? Pedro Oliveira wrote: > Tom 'spot' Callaway wrote: > > All of the specs and SRPMs can be found in here: > > http://auroralinux.org/people/spot/review/Maypole/ > > ... > > perl-Exporter-Lite: > > Lightweight exporting of variables > > Notes: > * the changelog release doesn't match the package release > * the license can't be confirmed (GPL or Artistic). > > The author being who he is, it will most likely be > "GPL or Artistic" (same as Perl itself) but for the > moment we should use distributable. Confirmed the license as "GPL or Artistic" with upstream. Fixed the release to match the changelog. New SPRM and SPEC: SRPM: http://www.auroralinux.org/people/spot/review/Maypole/perl-Exporter-Lite-0.01-2.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/Maypole/perl-Exporter-Lite.spec Please re-review or approve. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Thu Jul 28 03:54:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 22:54:14 -0500 Subject: Review: perl-SQL-Abstract In-Reply-To: <42D2C66E.4060902@di.uminho.pt> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2C66E.4060902@di.uminho.pt> Message-ID: <1122522854.2645.31.camel@localhost.localdomain> On Mon, 2005-07-11 at 20:20 +0100, Jos? Pedro Oliveira wrote: > Tom 'spot' Callaway wrote: > > > > All of the specs and SRPMs can be found in here: > > http://auroralinux.org/people/spot/review/Maypole/ > > ... > > perl-SQL-Abstract: > > Generate SQL from Perl data structures > > Note: > * the changelog release doesn't match the package release Fixed in -2: SRPM: http://www.auroralinux.org/people/spot/review/Maypole/perl-SQL-Abstract-1.19-2.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/Maypole/perl-SQL-Abstract.spec Please re-review or approve. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From buildsys at fedoraproject.org Thu Jul 28 03:54:15 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jul 2005 23:54:15 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050728035415.63BBC7FE4@extras64> Packages built and released for Fedora Extras 4: 31 Coin2-2.4.3-1.fc4 TeXmacs-1.0.5.6-2.fc4 bash-completion-20050721-1.fc4 bwm-ng-0.5-5.fc4 cd-discid-0.9-3.fc4.1 clamav-0.86.2-2.fc4 contact-lookup-applet-0.13-1.fc4 fish-1.11.1-10.fc4 fish-1.12.0-1.fc4 flumotion-0.1.9-1.fc4 freeciv-2.0.3-1.fc4 galculator-1.2.5-1.fc4 gcfilms-5.3-1.fc4 gkrellm-aclock-0.3.3-1.fc4 id3lib-3.8.3-12.fc4 kinput2-v3.1-26.fc4 libcdio-0.75-3.fc4 libdnet-1.10-2.fc4 libxml++-2.10.0-1.fc4 liferea-0.9.4-1.fc4 lighttpd-1.3.15-1.fc4 mod_security-1.8.7-4.fc4 moodss-20.3-1.fc4 pam_abl-0.2.2-2.fc4 perl-Crypt-CBC-2.14-2.fc4 perl-ExtUtils-XSBuilder-0.27-2.fc4 rpmlint-0.70-4.fc4 showimg-0.9.4.1-4.fc4 tetex-lgrind-3.67-6.1 ulogd-1.23-2.fc4 xemacs-sumo-20050715-1 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From tcallawa at redhat.com Thu Jul 28 03:59:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 22:59:23 -0500 Subject: Review: perl-Test-MockModule In-Reply-To: <42D2CC8E.3040801@di.uminho.pt> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2CC8E.3040801@di.uminho.pt> Message-ID: <1122523163.2645.33.camel@localhost.localdomain> On Mon, 2005-07-11 at 20:46 +0100, Jos? Pedro Oliveira wrote: > Tom 'spot' Callaway wrote: > > ... > > All of the specs and SRPMs can be found in here: > > http://auroralinux.org/people/spot/review/Maypole/ > > ... > > perl-Test-MockModule: > > Override subroutines in a module for unit testing > > Needwork: > * missing build requirements. For better test suite coverage > include the following line: > > BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage) Fixed in -3: SRPM: http://www.auroralinux.org/people/spot/review/Maypole/perl-Test-MockModule-0.05-3.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/Maypole/perl-Test-MockModule.spec Please re-review or approve. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ianburrell at gmail.com Thu Jul 28 04:04:08 2005 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 27 Jul 2005 21:04:08 -0700 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <1122512805.2645.14.camel@localhost.localdomain> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> Message-ID: On 7/27/05, Tom 'spot' Callaway wrote: > > > > For functionality enhancing packages.. do I use perl packaging like > > provides/requires syntax? > > Well, I don't think rpm understands ruby(function), and there are no > pre-existant macros that I'm aware of. But otherwise, the perl model > should be sufficient. > Ruby is more similar to Python in loading files. It loads files, with relative paths in the site_lib directory. The files can contain multiple classes which don't need to be named like the file. Unfortunately, like Python, there is no relation between the files installed and how they are distributed. This is different than Perl where almost every class goes in a file named after the class. And most modern modules are named after the primary class. - Ian From jpo at di.uminho.pt Thu Jul 28 04:15:30 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Thu, 28 Jul 2005 05:15:30 +0100 Subject: Review: perl-Exporter-Lite In-Reply-To: <1122522709.2645.30.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2C266.6080202@di.uminho.pt> <1122522709.2645.30.camel@localhost.localdomain> Message-ID: <42E85BE2.80600@di.uminho.pt> Tom 'spot' Callaway wrote: > On Mon, 2005-07-11 at 20:03 +0100, Jos? Pedro Oliveira wrote: > >>Tom 'spot' Callaway wrote: >> >>>All of the specs and SRPMs can be found in here: >>>http://auroralinux.org/people/spot/review/Maypole/ >>>... >>>perl-Exporter-Lite: >>>Lightweight exporting of variables >> >>Notes: >>* the changelog release doesn't match the package release >>* the license can't be confirmed (GPL or Artistic). >> >> The author being who he is, it will most likely be >> "GPL or Artistic" (same as Perl itself) but for the >> moment we should use distributable. > > > Confirmed the license as "GPL or Artistic" with upstream. > Fixed the release to match the changelog. > > New SPRM and SPEC: > SRPM: > http://www.auroralinux.org/people/spot/review/Maypole/perl-Exporter-Lite-0.01-2.src.rpm > SPEC: > http://www.auroralinux.org/people/spot/review/Maypole/perl-Exporter-Lite.spec > > Please re-review or approve. > > ~spot Approved. jpo PS - License can be checked here: http://rt.cpan.org/NoAuth/Bug.html?id=13648 -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Thu Jul 28 04:15:54 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Thu, 28 Jul 2005 05:15:54 +0100 Subject: Review: perl-SQL-Abstract In-Reply-To: <1122522854.2645.31.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2C66E.4060902@di.uminho.pt> <1122522854.2645.31.camel@localhost.localdomain> Message-ID: <42E85BFA.5060908@di.uminho.pt> Tom 'spot' Callaway wrote: > On Mon, 2005-07-11 at 20:20 +0100, Jos? Pedro Oliveira wrote: > >>Tom 'spot' Callaway wrote: >> >>>All of the specs and SRPMs can be found in here: >>>http://auroralinux.org/people/spot/review/Maypole/ >>>... >>>perl-SQL-Abstract: >>>Generate SQL from Perl data structures >> >>Note: >>* the changelog release doesn't match the package release > > > Fixed in -2: > > SRPM: > http://www.auroralinux.org/people/spot/review/Maypole/perl-SQL-Abstract-1.19-2.src.rpm > SPEC: > http://www.auroralinux.org/people/spot/review/Maypole/perl-SQL-Abstract.spec > > Please re-review or approve. > > ~spot Approved. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Thu Jul 28 04:16:12 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Thu, 28 Jul 2005 05:16:12 +0100 Subject: Review: perl-Test-MockModule In-Reply-To: <1122523163.2645.33.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2CC8E.3040801@di.uminho.pt> <1122523163.2645.33.camel@localhost.localdomain> Message-ID: <42E85C0C.9020006@di.uminho.pt> Tom 'spot' Callaway wrote: > On Mon, 2005-07-11 at 20:46 +0100, Jos? Pedro Oliveira wrote: > >>Tom 'spot' Callaway wrote: >> >>>... >>>All of the specs and SRPMs can be found in here: >>>http://auroralinux.org/people/spot/review/Maypole/ >>>... >>>perl-Test-MockModule: >>>Override subroutines in a module for unit testing >> >>Needwork: >>* missing build requirements. For better test suite coverage >> include the following line: >> >> BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage) > > > Fixed in -3: > > SRPM: > http://www.auroralinux.org/people/spot/review/Maypole/perl-Test-MockModule-0.05-3.src.rpm > SPEC: > http://www.auroralinux.org/people/spot/review/Maypole/perl-Test-MockModule.spec > > Please re-review or approve. > > Thanks, > > ~spot Approved. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From florin at andrei.myip.org Thu Jul 28 05:25:47 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 27 Jul 2005 22:25:47 -0700 Subject: zope: missing dependency Message-ID: <1122528347.2934.1.camel@rivendell.home.local> Whoever maintains the zope package - there's a missing dependency for PIL. I installed it on a clean FC4 system but when running "zopectl adduser" I get this: # ./zopectl adduser XXXXXXXX YYYYYYYYY /usr/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module DeprecationWarning) /usr/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module DeprecationWarning) 2005-07-27 22:20:27 WARNING PortalTransforms Unable to find binary "pdftohtml" in /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin 2005-07-27 22:20:27 WARNING PortalTransforms Unable to find binary "pdftotext" in /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin 2005-07-27 22:20:27 WARNING PortalTransforms Unable to find binary "rtf-converter" in /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin 2005-07-27 22:20:27 WARNING PortalTransforms Unable to find binary "rtf2xml" in /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin 2005-07-27 22:20:31 WARNING ZODB.FileStorage Ignoring index for /var/lib/zope/var/Data.fs 2005-07-27 22:20:32 ERROR Plone Dependency PIL not found. Plone needs PIL 1.1.5 or newer to scale images. Please download it from http://www.pythonware.com/products/pil/ or http://effbot.org/downloads/#Imaging -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Thu Jul 28 05:29:02 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 27 Jul 2005 22:29:02 -0700 Subject: zope: missing dependency In-Reply-To: <1122528347.2934.1.camel@rivendell.home.local> References: <1122528347.2934.1.camel@rivendell.home.local> Message-ID: <1122528542.2934.3.camel@rivendell.home.local> On Wed, 2005-07-27 at 22:25 -0700, Florin Andrei wrote: > Whoever maintains the zope package - there's a missing dependency for > PIL. I installed it on a clean FC4 system but when running "zopectl > adduser" I get this: > > # ./zopectl adduser XXXXXXXX YYYYYYYYY [...] > 2005-07-27 22:20:32 ERROR Plone Dependency > PIL not found. Plone needs PIL 1.1.5 or newer to scale images. Please > download it from http://www.pythonware.com/products/pil/ or > http://effbot.org/downloads/#Imaging Perhaps I should be more explicit: the dependency is python-imaging -- Florin Andrei http://florin.myip.org/ From skvidal at phy.duke.edu Thu Jul 28 05:41:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 01:41:18 -0400 Subject: build status part deux In-Reply-To: <1122503573.5406.8.camel@bree.local.net> References: <1122493556.7082.44.camel@cutter> <1122503573.5406.8.camel@bree.local.net> Message-ID: <1122529279.13300.10.camel@cutter> On Wed, 2005-07-27 at 18:32 -0400, Jeremy Katz wrote: > On Wed, 2005-07-27 at 15:45 -0400, seth vidal wrote: > > We got all the fc3 builds finished and done. > > Rawhide is a bit unusuable right now so I'm deferring development builds > > and we're trying to get all the fc4 builds done. We've been having a bit > > of trouble with the ppc builds box and we're trying to figure out why it > > is flaking out. > > And it looks like we now have working ppc builds. Going from a 32bit > ppc box to a 64bit ppc box involved working through some not entirely > obvious at first problems, but those are looking to be pretty happy > now. > > I'll check back on things once I get home to make sure things are > continuing to go happily and to start working towards bringing up the > other build machines. > As soon as rawhide is installable again I'll submit all the devel builds and see how they return. -sv From buildsys at fedoraproject.org Thu Jul 28 08:00:28 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jul 2005 04:00:28 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050728080028.9025D7FE6@extras64> Packages built and released for Fedora Extras 4: 2 libcddb-1.2.0-2.fc4 notecase-1.0.0-1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From roland at redhat.com Thu Jul 28 08:13:36 2005 From: roland at redhat.com (Roland McGrath) Date: Thu, 28 Jul 2005 01:13:36 -0700 (PDT) Subject: build failed from bad repodata Message-ID: <20050728081336.46276180EB8@magilla.sf.frob.com> What am I supposed to do about this? (http://buildsys.fedoraproject.org/logs//4/52-monotone-0.21-2.fc4/) Just "make build" again, or what? /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-x86_64-core-9c30d592682cbff5339085dd4c13c7511dcae967/root groupinstall build http://fedoraproject.org/extras/4/x86_64/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/filelists.xml.gz from extras: [Errno 256] No more mirrors to try. From skvidal at phy.duke.edu Thu Jul 28 08:18:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 04:18:33 -0400 Subject: build failed from bad repodata In-Reply-To: <20050728081336.46276180EB8@magilla.sf.frob.com> References: <20050728081336.46276180EB8@magilla.sf.frob.com> Message-ID: <1122538713.13300.24.camel@cutter> On Thu, 2005-07-28 at 01:13 -0700, Roland McGrath wrote: > What am I supposed to do about this? > (http://buildsys.fedoraproject.org/logs//4/52-monotone-0.21-2.fc4/) > > Just "make build" again, or what? > > > /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-x86_64-core-9c30d592682cbff5339085dd4c13c7511dcae967/root groupinstall build > http://fedoraproject.org/extras/4/x86_64/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum > Trying other mirror. > Error: failure: repodata/filelists.xml.gz from extras: [Errno 256] No more mirrors to try. > leave it alone - I'll resubmit it. The packages were pushed at the wrong time. -sv From wtogami at redhat.com Thu Jul 28 08:30:25 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 27 Jul 2005 22:30:25 -1000 Subject: build failed from bad repodata In-Reply-To: <1122538713.13300.24.camel@cutter> References: <20050728081336.46276180EB8@magilla.sf.frob.com> <1122538713.13300.24.camel@cutter> Message-ID: <42E897A1.8040801@redhat.com> seth vidal wrote: > On Thu, 2005-07-28 at 01:13 -0700, Roland McGrath wrote: > >>What am I supposed to do about this? >>(http://buildsys.fedoraproject.org/logs//4/52-monotone-0.21-2.fc4/) >> >>Just "make build" again, or what? >> >> >>/usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-x86_64-core-9c30d592682cbff5339085dd4c13c7511dcae967/root groupinstall build >>http://fedoraproject.org/extras/4/x86_64/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum >>Trying other mirror. >>Error: failure: repodata/filelists.xml.gz from extras: [Errno 256] No more mirrors to try. >> > > > leave it alone - I'll resubmit it. The packages were pushed at the wrong > time. > I consider this to be a minor design flaw. It is not good that the pusher needs to watch asynchronous events and wait for the perfect time in order to push without causing other parts of the build system to fail. The system could be improved in the future to be robust enough to handle this. Maybe it could detect this particular error and restart the BuildRequires population from the beginning after a pause, maybe the existence of a lockfile? This is low priority to fix for now because it is easy to avoid now that I know about the problem. Warren Togami wtogami at redhat.com From dragoran at feuerpokemon.de Thu Jul 28 12:20:52 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 28 Jul 2005 14:20:52 +0200 Subject: Fedora Extras 4 Package Build Report In-Reply-To: <20050728080028.9025D7FE6@extras64> References: <20050728080028.9025D7FE6@extras64> Message-ID: <42E8CDA4.5070406@feuerpokemon.de> buildsys at fedoraproject.org wrote: >Packages built and released for Fedora Extras 4: 2 > >libcddb-1.2.0-2.fc4 >notecase-1.0.0-1.fc4 > > >For more information about the built packages please see the repository >or the fedora Info Feed: http://fedoraproject.org/infofeed/ > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > libcddb and libcdio are still broken (don't let me install vcdimager from livna or freshrpms): Processing Dependency: libcdio.so.5()(64bit) for package: vcdimager --> Processing Dependency: libcdio.so.5(CDIO_5)(64bit) for package: vcdimager --> Finished Dependency Resolution Error: Missing Dependency: libcdio.so.5()(64bit) is needed by package vcdimager Error: Missing Dependency: libcdio.so.5(CDIO_5)(64bit) is needed by package vcdimager From ivazquez at ivazquez.net Thu Jul 28 10:29:12 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 06:29:12 -0400 Subject: Fedora Extras 4 Package Build Report In-Reply-To: <42E8CDA4.5070406@feuerpokemon.de> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> Message-ID: <1122546552.5381.4.camel@ignacio.lan> On Thu, 2005-07-28 at 14:20 +0200, dragoran wrote: > libcddb and libcdio are still broken (don't let me install vcdimager > from livna or freshrpms): At this point it's up to them to rebuild their packages. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 nwolovick at gmail.com Thu Jul 28 10:24:25 2005 From: nwolovick at gmail.com (=?ISO-8859-1?Q?Nicol=E1s_Wolovick?=) Date: Thu, 28 Jul 2005 07:24:25 -0300 Subject: Request for review: gnome-applet-bubblemon Message-ID: I'd like this nice and little and applet to be reviewed. gnome-applet-bubblemon: This is a panel applet that displays the CPU and memory load as a bubbling liquid. The latest version is available off http://savannah.nongnu.org/download/bubblemon/. Choose Add to Panel->Utility->Bubblemon in your GNOME Panel. SPEC:http://www.cs.famaf.unc.edu.ar/~nicolasw/Otros/gnome-applet-bubblemon.spec SRPM:http://www.cs.famaf.unc.edu.ar/~nicolasw/Otros/gnome-applet-bubblemon-2.0.4-3.fc4.src.rpm I've used rpmlint and I got one warning that according to https://www.redhat.com/archives/fedora-extras-list/2005-May/msg01024.html is not important. A different package name from the original applet name "bubblemon" was used in order to make it more precise. Feedback is welcome. Regards, Nicolas From bugs.michael at gmx.net Thu Jul 28 11:01:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Jul 2005 13:01:28 +0200 Subject: libcdio/libcddb (was: Re: Fedora Extras 4 Package Build Report) In-Reply-To: <42E8CDA4.5070406@feuerpokemon.de> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> Message-ID: <20050728130128.6c7d3b0e.bugs.michael@gmx.net> On Thu, 28 Jul 2005 14:20:52 +0200, dragoran wrote: > libcddb and libcdio are still broken (don't let me install vcdimager > from livna or freshrpms): > Processing Dependency: libcdio.so.5()(64bit) for package: vcdimager What makes you think it should be fixed already? The fix is still not complete, and that is a known thing. Btw, vcdimager at livna/freshrpms would need to be rebuilt, too, unless somebody provides a compatability-package there, e.g. libcdio0-1.0.2... From rc040203 at freenet.de Thu Jul 28 12:13:20 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 28 Jul 2005 14:13:20 +0200 Subject: libcdio/libcddb (was: Re: Fedora Extras 4 Package Build Report) In-Reply-To: <20050728130128.6c7d3b0e.bugs.michael@gmx.net> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> <20050728130128.6c7d3b0e.bugs.michael@gmx.net> Message-ID: <1122552800.19663.24.camel@mccallum.corsepiu.local> On Thu, 2005-07-28 at 13:01 +0200, Michael Schwendt wrote: > On Thu, 28 Jul 2005 14:20:52 +0200, dragoran wrote: > > > libcddb and libcdio are still broken (don't let me install vcdimager > > from livna or freshrpms): > > Processing Dependency: libcdio.so.5()(64bit) for package: vcdimager > > What makes you think it should be fixed already? > The fix is still not complete, and that is a known thing. > > Btw, vcdimager at livna/freshrpms would need to be rebuilt, too, > unless somebody provides a compatability-package there, e.g. > libcdio0-1.0.2... Well, what actually has happened raises much more general questions. What has happened: A major update of a package in FE has broken compatibility (SONAME change). As far as Livna is concerned, rebuilding all affected packages at livna will close this issue locally for Livna, but ... FE has broken its API and will have broken other packages elsewhere. The question now is: Is FE supposed to provide a fixed API, and therefore to provide compatibility packages in general? It's basically the same problem FC circumvents by occasionally not adopting major updates (Consider Gnome, KDE, GCC, Libc) or by providing compatibility packages. IMO, the only fair and correct policy would be FE to providing compatibility packages. Ralf From ivazquez at ivazquez.net Thu Jul 28 12:42:17 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 08:42:17 -0400 Subject: Request for review: gnome-applet-bubblemon In-Reply-To: References: Message-ID: <1122554538.5381.25.camel@ignacio.lan> On Thu, 2005-07-28 at 07:24 -0300, Nicol?s Wolovick wrote: > SPEC:http://www.cs.famaf.unc.edu.ar/~nicolasw/Otros/gnome-applet-bubblemon.spec - Remove the hardcoded disttags - Remove the explicit Requires - --prefix and --mandir are redundant with %configure - Variables should come after make in the command line, not before - Use install, not install-strip in %install - Should not own %{_datadir}/gnome-2.0 - Use %find_lang instead of owning %{_datadir}/locale -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 bugs.michael at gmx.net Thu Jul 28 12:45:14 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Jul 2005 14:45:14 +0200 Subject: libcdio/libcddb (was: Re: Fedora Extras 4 Package Build Report) In-Reply-To: <1122552800.19663.24.camel@mccallum.corsepiu.local> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> <20050728130128.6c7d3b0e.bugs.michael@gmx.net> <1122552800.19663.24.camel@mccallum.corsepiu.local> Message-ID: <20050728144514.2f19e748.bugs.michael@gmx.net> On Thu, 28 Jul 2005 14:13:20 +0200, Ralf Corsepius wrote: > Well, what actually has happened raises much more general questions. > > What has happened: A major update of a package in FE has broken > compatibility (SONAME change). > > As far as Livna is concerned, rebuilding all affected packages at livna > will close this issue locally for Livna, but ... FE has broken its API > and will have broken other packages elsewhere. It broke the ABI, that's worse. > The question now is: Are we permitted to break ABI/API in updates or only for the next release of the distribution? How do we handle ABI/API breakage generally? > Is FE supposed to provide a fixed API, and therefore to provide > compatibility packages in general? A compatibility package like the aforementioned libcddb0-1.0.2 would fix the ABI breakage, but create API breakage in case you also want a compatibility -devel package (to make the old and new libcddb co-exist, you would need to relocate the files of either one). > It's basically the same problem FC > circumvents by occasionally not adopting major updates (Consider Gnome, > KDE, GCC, Libc) or by providing compatibility packages. > > IMO, the only fair and correct policy would be FE to providing > compatibility packages. The easiest solution, but only for compatibility DSOs, not a separate -devel package. From rc040203 at freenet.de Thu Jul 28 12:55:49 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 28 Jul 2005 14:55:49 +0200 Subject: libcdio/libcddb (was: Re: Fedora Extras 4 Package Build Report) In-Reply-To: <20050728144514.2f19e748.bugs.michael@gmx.net> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> <20050728130128.6c7d3b0e.bugs.michael@gmx.net> <1122552800.19663.24.camel@mccallum.corsepiu.local> <20050728144514.2f19e748.bugs.michael@gmx.net> Message-ID: <1122555349.19663.42.camel@mccallum.corsepiu.local> On Thu, 2005-07-28 at 14:45 +0200, Michael Schwendt wrote: > On Thu, 28 Jul 2005 14:13:20 +0200, Ralf Corsepius wrote: > > > Well, what actually has happened raises much more general questions. > > > > What has happened: A major update of a package in FE has broken > > compatibility (SONAME change). > > > > As far as Livna is concerned, rebuilding all affected packages at livna > > will close this issue locally for Livna, but ... FE has broken its API > > and will have broken other packages elsewhere. > > It broke the ABI, that's worse. > > > The question now is: > > Are we permitted to break ABI/API in updates or only for the next > release of the distribution? IMO, in general no. FE should adopt a similar policy as FC seems to apply. > How do we handle ABI/API breakage generally? IMO, a case-by-case based decisions would be appropriate. * For exotic/rarely used packages, we probably do not have to care much (Who decides and how?). * For packages with a small set of applications using it (such as libcdio/libcddb), providing compatibility run-time packages probably will suffice. * For widely used packages, packages should be designed for parallel installation. * For vital and very widely used packages (I am not aware of any in FE), skipping updates probably would be best. > > It's basically the same problem FC > > circumvents by occasionally not adopting major updates (Consider Gnome, > > KDE, GCC, Libc) or by providing compatibility packages. > > > > IMO, the only fair and correct policy would be FE to providing > > compatibility packages. > > The easiest solution, but only for compatibility DSOs, not a > separate -devel package. I guess, this would suffice in the libcdio, libcddb case. Ralf From jspaleta at gmail.com Thu Jul 28 13:05:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 09:05:38 -0400 Subject: build status part deux In-Reply-To: <1122529279.13300.10.camel@cutter> References: <1122493556.7082.44.camel@cutter> <1122503573.5406.8.camel@bree.local.net> <1122529279.13300.10.camel@cutter> Message-ID: <604aa79105072806057ce84c4f@mail.gmail.com> On 7/28/05, seth vidal wrote: > As soon as rawhide is installable again I'll submit all the devel builds > and see how they return. the rpm dep problem has been fixed in today's rawhide tree so rawhide should be installable again.. at least for today. -jef From jspaleta at gmail.com Thu Jul 28 13:46:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 09:46:00 -0400 Subject: Fedora Extras 4 Package Build Report In-Reply-To: <42E8CDA4.5070406@feuerpokemon.de> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> Message-ID: <604aa791050728064673817a1f@mail.gmail.com> On 7/28/05, dragoran wrote: > libcddb and libcdio are still broken (don't let me install vcdimager > from livna or freshrpms): You need to be more careful about what you mean by 'broken' and where you point the finger. In this case Fedora Extras is no longer broken.. the libcddb and libcdio packages form a self-consistent set. The problem is the updated versions include new versions of the libraries that are incompatible with the older livna and freshrpms packages. The 'breaking' of depchains across repository boundaries is very very hard to avoid as long as Fedora Extras continues to use a rolling release model that allows for updates to include new libraries that change ABI and API. In this respect Fedora Extras shares some characteristics with rawhide. Once you start talking about dependancy problems across any repository boundary things get really complicated. Core updates on occasion will 'break' Extras packages in a similar fashion until Extras catches up, more so with Core development. Notwithstanding a shift in the rolling policy, there are potential ways to make it easier for 3rd party repos to catch up before an ABI/API breaking update is pushed to the consumable FE tree. There could be a minimal amount of time that new updates sit in a "pending" repo and 3rd party repos can run scripted runs of repoclosure against FE and FE-pending as well as their own repos. Runs of repoclosure in this way would give 3rd party maintainers a headsup about impending dep chain breakages and give them a finite time to respond with updates to their packages or to talk with the FE maintainer and work out another arrangement like providing a compatibility package in FE if that is the more appropriate solution. -jef From alex at dalloz.de Thu Jul 28 14:23:19 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Thu, 28 Jul 2005 16:23:19 +0200 Subject: zope: missing dependency In-Reply-To: <1122528542.2934.3.camel@rivendell.home.local> References: <1122528347.2934.1.camel@rivendell.home.local> <1122528542.2934.3.camel@rivendell.home.local> Message-ID: <1122560599.3683.103.camel@serendipity.dogma.lan> Am Do, den 28.07.2005 schrieb Florin Andrei um 7:29: > On Wed, 2005-07-27 at 22:25 -0700, Florin Andrei wrote: > > Whoever maintains the zope package - there's a missing dependency for > > PIL. I installed it on a clean FC4 system but when running "zopectl > > adduser" I get this: > > > > # ./zopectl adduser XXXXXXXX YYYYYYYYY > [...] > > 2005-07-27 22:20:32 ERROR Plone Dependency > > PIL not found. Plone needs PIL 1.1.5 or newer to scale images. Please > > download it from http://www.pythonware.com/products/pil/ or > > http://effbot.org/downloads/#Imaging > > Perhaps I should be more explicit: the dependency is python-imaging Please file a bugzilla ticket. Aurelien Bompard who is the Zope and Plone maintainer may not read this list constantly and bugs should generally be reported by bugzilla to be able to track them. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From alex at dalloz.de Thu Jul 28 14:36:22 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Thu, 28 Jul 2005 16:36:22 +0200 Subject: Request for review: lzo2 Message-ID: <1122561382.3683.115.camel@serendipity.dogma.lan> LZO -- a real-time data compression library While we have "lzo" already in Extras, in version 1.08, I like to have the new version in there in parallel. So I named it "lzo2". It can be installed in parallel to the "lzo 1" as the programmer took care for this. From ChangeLog http://www.oberhumer.com/opensource/lzo/lzonews.php "Changes in 2.01 (27 Jun 2005) * Changed the configure system to install the LZO library under the name "liblzo2" so that parallel installation with LZO v1 is possible." lzo 1.08 needs to stay in Fedora Extas for other packages build against it. NewRequest for review: lzo2er packages could use lzo2 in future, like upcoming OpenVPN 2.0.1 is prepared for it. http://www.oberhumer.com/opensource/lzo/ "LZO 2.01 has been released, featuring major speedups for 64-bit architectures like AMD64, minor overall speedups, portability enhancements for LLP64 programming models, and lots of other small improvements." spec file and src.rpm for a review: http://www.uni-x.org/review/lzo2.spec http://www.uni-x.org/review/lzo2-2.01-1.src.rpm Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jamatos at fc.up.pt Thu Jul 28 14:45:54 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 15:45:54 +0100 Subject: Re-Request for review: pytz and python-dateutil In-Reply-To: <42E15B73.1090108@cora.nwra.com> References: <42DE7D8A.30100@cora.nwra.com> <200507222015.12998.jamatos@fc.up.pt> <42E15B73.1090108@cora.nwra.com> Message-ID: <200507281545.54622.jamatos@fc.up.pt> On Friday 22 July 2005 21:47, Orion Poplawski wrote: > > ? - Is it really necessary to make all python files executable? I don't > > see this rule anywhere... > > > > ? If the last item is supported by any more experienced packager then > > consider this as approved. > > I think I did it to shutup a rpmlint warning about non-executable > scripts. ?If it does no harm (?) I'll leave it in. I think that the execution bits should be off, but this is a minor point and we don't have any official policy about this issue so consider this package approved. I sent the approval message for both pytz and python-dateutil to cvs commit list. So now there is nothing preventing you from presenting matplotlib for review. ;-) -- Jos? Ab?lio From ivazquez at ivazquez.net Thu Jul 28 15:21:48 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 11:21:48 -0400 Subject: Request for review: lzo2 In-Reply-To: <1122561382.3683.115.camel@serendipity.dogma.lan> References: <1122561382.3683.115.camel@serendipity.dogma.lan> Message-ID: <1122564109.5381.27.camel@ignacio.lan> On Thu, 2005-07-28 at 16:36 +0200, Alexander Dalloz wrote: > http://www.uni-x.org/review/lzo2.spec - Erase the .la file instead of using %exclude -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 paul at city-fan.org Thu Jul 28 15:21:47 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 28 Jul 2005 16:21:47 +0100 Subject: Request for review: lzo2 In-Reply-To: <1122564109.5381.27.camel@ignacio.lan> References: <1122561382.3683.115.camel@serendipity.dogma.lan> <1122564109.5381.27.camel@ignacio.lan> Message-ID: <1122564107.2851.42.camel@laurel.intra.city-fan.org> On Thu, 2005-07-28 at 11:21 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-07-28 at 16:36 +0200, Alexander Dalloz wrote: > > http://www.uni-x.org/review/lzo2.spec > > - Erase the .la file instead of using %exclude Why? Paul. -- Paul Howarth From alex at dalloz.de Thu Jul 28 15:26:38 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Thu, 28 Jul 2005 17:26:38 +0200 Subject: Request for review: lzo2 In-Reply-To: <1122564109.5381.27.camel@ignacio.lan> References: <1122561382.3683.115.camel@serendipity.dogma.lan> <1122564109.5381.27.camel@ignacio.lan> Message-ID: <1122564398.3683.130.camel@serendipity.dogma.lan> Am Do, den 28.07.2005 schrieb Ignacio Vazquez-Abrams um 17:21: > On Thu, 2005-07-28 at 16:36 +0200, Alexander Dalloz wrote: > > http://www.uni-x.org/review/lzo2.spec > > - Erase the .la file instead of using %exclude I have no problem to do so. Would be kind if you could explain me why the "%exclude" is wrong. It is the same as used in the lzo-1.08 Extras package spec. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jamatos at fc.up.pt Thu Jul 28 15:34:14 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 16:34:14 +0100 Subject: Review of pyparsing Message-ID: <200507281634.14704.jamatos@fc.up.pt> Hi Ignacio, I have only joined this list later so I will break the thread, I am sorry. The original thread is here: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00429.html I got the package from: http://fedora.ivazquez.net/files/extras/pyparsing-1.3-1.src.rpm The package is minimalist, to say the least ;-). I don't understand why the package does not ship any documentation, as well as the examples. If you fix this I will approve the package. -- Jos? Ab?lio From jamatos at fc.up.pt Thu Jul 28 15:41:26 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 16:41:26 +0100 Subject: Request to edit CVSSyncNeeded Message-ID: <200507281641.27210.jamatos@fc.up.pt> Hi, I would like to be able to edit CVSSyncNeeded, my user name is jamatos in the wiki. Thanks, -- Jos? Ab?lio From gauret at free.fr Thu Jul 28 15:49:17 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 28 Jul 2005 17:49:17 +0200 Subject: zope: missing dependency References: <1122528347.2934.1.camel@rivendell.home.local> <1122528542.2934.3.camel@rivendell.home.local> <1122560599.3683.103.camel@serendipity.dogma.lan> Message-ID: Alexander Dalloz wrote: > Am Do, den 28.07.2005 schrieb Florin Andrei um 7:29: >> Perhaps I should be more explicit: the dependency is python-imaging > > Please file a bugzilla ticket. Aurelien Bompard who > is the Zope and Plone maintainer may not read this list constantly and > bugs should generally be reported by bugzilla to be able to track them. Yes, thanks for the report. I've been away from computers for a couple of weeks and I'm catching up slowly. Bugzilla helps a lot. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From ivazquez at ivazquez.net Thu Jul 28 15:58:03 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 11:58:03 -0400 Subject: Request for review: lzo2 In-Reply-To: <1122564107.2851.42.camel@laurel.intra.city-fan.org> References: <1122561382.3683.115.camel@serendipity.dogma.lan> <1122564109.5381.27.camel@ignacio.lan> <1122564107.2851.42.camel@laurel.intra.city-fan.org> Message-ID: <1122566283.5381.30.camel@ignacio.lan> On Thu, 2005-07-28 at 16:21 +0100, Paul Howarth wrote: > On Thu, 2005-07-28 at 11:21 -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2005-07-28 at 16:36 +0200, Alexander Dalloz wrote: > > > http://www.uni-x.org/review/lzo2.spec > > > > - Erase the .la file instead of using %exclude > > Why? On Thu, 2005-07-28 at 17:26 +0200, Alexander Dalloz wrote: > I have no problem to do so. Would be kind if you could explain me why > the "%exclude" is wrong. It is the same as used in the lzo-1.08 Extras > package spec. It messes up the package's metadata. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89661 -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 joost at cnoc.nl Thu Jul 28 15:54:22 2005 From: joost at cnoc.nl (Joost van der Sluis) Date: Thu, 28 Jul 2005 17:54:22 +0200 Subject: Request for sponsor and review of: lazarus and fpc In-Reply-To: <42E17802.7050902@cora.nwra.com> References: <1121958861.18178.29.camel@joost> <42E17802.7050902@cora.nwra.com> Message-ID: <1122566062.30099.16.camel@joost> Thanks again for your work. It took somehting longer for me to fix things then I thought, but I was to busy with my job the last few days: > BAD: > > - spec file should be ftp.spec, no version. Release should probably be "1" Fixed > - COPYING not included as %doc Fixed > - Missing BuildRequires: binutils, gpm-devel, some (la)tex package > (may be others, I don't have mock setup) Fixed partly. I can't find which (la)tex package is missing. I uninstalled almost everything, including docbook and openjade. Are you sure about this? > - why a "src" package? (Also note fpc-doc type in %desc). > You've already got a src.rpm. The source package is neede by Lazarus, which is in fact a GUI-IDE for Freepascal. The src.rpm doesn't work here, since if you install it, you don't have the sources on your system, but only a tarball with the sources. You could compare it to a .devel-package. Only Pascal doesn't know such thing as a devel-package, but Lazarus does need some definitions which it gets from the freepascal-sources. That's why there's a .src package. > POSSIBLY VERY BAD: > > - tar.gz of binary executables as part of the package! > > MINOR: > > - Remove commented out *Requires: lines from spec Fixed. New version is available at: http://www.cnoc.nl/fpc/fpc.spec http://www.cnoc.nl/fpc/fpc-2.0.0-1.src.rpm Regards, Joost From ivazquez at ivazquez.net Thu Jul 28 16:25:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 12:25:26 -0400 Subject: Review of pyparsing In-Reply-To: <200507281634.14704.jamatos@fc.up.pt> References: <200507281634.14704.jamatos@fc.up.pt> Message-ID: <1122567926.5381.32.camel@ignacio.lan> On Thu, 2005-07-28 at 16:34 +0100, Jose' Matos wrote: > The package is minimalist, to say the least ;-). I don't understand why the > package does not ship any documentation, as well as the examples. I rebuilt it. Please re-review. http://fedora.ivazquez.net/files/extras/pyparsing.spec http://fedora.ivazquez.net/files/extras/pyparsing-1.3-1.src.rpm -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 notting at redhat.com Thu Jul 28 16:39:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 28 Jul 2005 12:39:00 -0400 Subject: libcdio/libcddb (was: Re: Fedora Extras 4 Package Build Report) In-Reply-To: <20050728144514.2f19e748.bugs.michael@gmx.net> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> <20050728130128.6c7d3b0e.bugs.michael@gmx.net> <1122552800.19663.24.camel@mccallum.corsepiu.local> <20050728144514.2f19e748.bugs.michael@gmx.net> Message-ID: <20050728163900.GD16154@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > Are we permitted to break ABI/API in updates or only for the next > release of the distribution? > > How do we handle ABI/API breakage generally? In Core it's *greatly* frowned upon to break the ABI in updates; it's better to save it for the next release. There are, of course, exceptions (the mozilla libs are the usual ones.) Bill From jspaleta at gmail.com Thu Jul 28 16:40:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 12:40:04 -0400 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <1122515871.2645.16.camel@localhost.localdomain> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> Message-ID: <604aa79105072809402c436ba2@mail.gmail.com> On 7/27/05, Tom 'spot' Callaway wrote: > Package it up, and I'll look it over. If we need to make packaging > policy changes, I'll help. first draft package that doesn't make any attempt yet to split off individual library bindings into seperate subpackages available at: http://jef.is--a-geek.com/downloads/ruby-gnome2-all/ I've built this in mock against x86 fc4 Clearly I'm going to want to split out the binary subpackages based on individual subdirectories of the full source tarball... tedious but not difficult to do. I'm more concerned about how rpm is catching the provided so files. There's no indication that the provides are libraries in ruby's site directory as compared to system lbraries. Is this going to be a problem? -jef rpm -q --provides -p ruby-gnome2-all/ruby-gnome2-all-0.12.0-1.i386.rpm atk.so gconf2.so gdk_pixbuf2.so glib2.so gnome2.so gnomecanvas2.so gnomeprint2.so gnomeprintui2.so gnomevfs.so gst.so gtk2.so gtk20.so gtk22.so gtkglext.so gtkhtml2.so gtksourceview.so libart2.so libgda.so libglade2.so panelapplet2.so pango.so rsvg2.so ruby-gnome2-all = 0.12.0-1 From nman64 at n-man.com Fri Jul 15 22:20:53 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 15 Jul 2005 17:20:53 -0500 Subject: WINE In-Reply-To: <1121464322.10327.38.camel@localhost> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> Message-ID: <42D836C5.9060306@n-man.com> The included objects are entirely from-scratch implementations of Microsoft's DLLs, but just because they don't directly violate copyrights doesn't mean they're in the clear. This is really something you should run past RH Legal. Patents are likely to be the bigger issue. I can't specifically name any conflicts raised so far, but then, Mono hasn't had any action taken against it either. We already know Microsoft has a large number of patents covering their technologies, and purely-original code isn't safe from that threat. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Thu Jul 28 17:14:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Jul 2005 19:14:43 +0200 Subject: Request to edit CVSSyncNeeded In-Reply-To: <200507281641.27210.jamatos@fc.up.pt> References: <200507281641.27210.jamatos@fc.up.pt> Message-ID: <20050728191443.139d815c.bugs.michael@gmx.net> On Thu, 28 Jul 2005 16:41:26 +0100, Jose' Matos wrote: > Hi, > I would like to be able to edit CVSSyncNeeded, my user name is jamatos in > the wiki. Unusual. Wiki account names usually are "Wiki words", which means, concatenated words like FooBar, where the first character of each word is capitalised. From sopwith at redhat.com Thu Jul 28 17:18:26 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 28 Jul 2005 13:18:26 -0400 (EDT) Subject: FE account system -- offline for now? In-Reply-To: <1122510643.7905.322.camel@ernie> References: <1122510643.7905.322.camel@ernie> Message-ID: I'm pretty sure Red Hat IS is in Mesa doing work at the colo, and they had mentioned taking things offline in order to improve the setup there. So it seems like today's the day... Best, -- Elliot On Wed, 27 Jul 2005, Ed Hill wrote: > I just searched though bugzilla.redhat.com and could find no place to > file this "bug" so please be patient with me while I email the list. > > Today, I pointed a new potential packager at: > > http://fedoraproject.org/wiki/Extras/Contributors > > and, apparently, its been unavailable all day today. What happened? > Will it be back anytime soon? > > thanks, > Ed > > From skvidal at phy.duke.edu Thu Jul 28 17:23:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 13:23:40 -0400 Subject: FE account system -- offline for now? In-Reply-To: References: <1122510643.7905.322.camel@ernie> Message-ID: <1122571420.19679.18.camel@cutter> On Thu, 2005-07-28 at 13:18 -0400, Elliot Lee wrote: > I'm pretty sure Red Hat IS is in Mesa doing work at the colo, and they > had mentioned taking things offline in order to improve the setup there. > So it seems like today's the day... > ah ha - that's why ppc1 went away. thank you! -sv From jamatos at fc.up.pt Thu Jul 28 17:47:47 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 18:47:47 +0100 Subject: Review of pyparsing In-Reply-To: <1122567926.5381.32.camel@ignacio.lan> References: <200507281634.14704.jamatos@fc.up.pt> <1122567926.5381.32.camel@ignacio.lan> Message-ID: <200507281847.47749.jamatos@fc.up.pt> On Thursday 28 July 2005 17:25, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-07-28 at 16:34 +0100, Jose' Matos wrote: > > The package is minimalist, to say the least ;-). I don't understand > > why the package does not ship any documentation, as well as the > > examples. > > I rebuilt it. Please re-review. > > http://fedora.ivazquez.net/files/extras/pyparsing.spec > http://fedora.ivazquez.net/files/extras/pyparsing-1.3-1.src.rpm The license text is missing from the package. The package seems to satisfy all the other requests and rpmlint only complains that there are no executable files but that warning is bogus. -- Jos? Ab?lio From jamatos at fc.up.pt Thu Jul 28 17:51:28 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 18:51:28 +0100 Subject: Request to edit CVSSyncNeeded In-Reply-To: <20050728191443.139d815c.bugs.michael@gmx.net> References: <200507281641.27210.jamatos@fc.up.pt> <20050728191443.139d815c.bugs.michael@gmx.net> Message-ID: <200507281851.28363.jamatos@fc.up.pt> On Thursday 28 July 2005 18:14, Michael Schwendt wrote: > On Thu, 28 Jul 2005 16:41:26 +0100, Jose' Matos wrote: > > Hi, > > I would like to be able to edit CVSSyncNeeded, my user name is jamatos > > in the wiki. > > Unusual. Wiki account names usually are "Wiki words", which means, > concatenated words like FooBar, where the first character of each > word is capitalised. And that is What I (didn't) Know Is (Was)... ;-) I never used a wiki before and it was never evident in the pages. Do you suggest to create another name account? Thanks, > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list -- Jos? Ab?lio From bugs.michael at gmx.net Thu Jul 28 18:17:11 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Jul 2005 20:17:11 +0200 Subject: Request to edit CVSSyncNeeded In-Reply-To: <200507281851.28363.jamatos@fc.up.pt> References: <200507281641.27210.jamatos@fc.up.pt> <20050728191443.139d815c.bugs.michael@gmx.net> <200507281851.28363.jamatos@fc.up.pt> Message-ID: <20050728201711.65248802.bugs.michael@gmx.net> On Thu, 28 Jul 2005 18:51:28 +0100, Jose' Matos wrote: > On Thursday 28 July 2005 18:14, Michael Schwendt wrote: > > On Thu, 28 Jul 2005 16:41:26 +0100, Jose' Matos wrote: > > > Hi, > > > I would like to be able to edit CVSSyncNeeded, my user name is jamatos > > > in the wiki. > > > > Unusual. Wiki account names usually are "Wiki words", which means, > > concatenated words like FooBar, where the first character of each > > word is capitalised. > > And that is What I (didn't) Know Is (Was)... ;-) > > I never used a wiki before and it was never evident in the pages. Do you > suggest to create another name account? Would be an idea, since you would be the only one to use a different account name. ;) http://fedoraproject.org/wiki/UserPreferences says: "(Use FirstnameLastname)" "It is best to choose a WikiName (like FirstnameLastname) as username to get your changes and signatures link back to your WikiHomepage." From orion at cora.nwra.com Thu Jul 28 19:42:17 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jul 2005 13:42:17 -0600 Subject: qsynaptics In-Reply-To: References: Message-ID: <42E93519.3010600@cora.nwra.com> Andreas Thienemann wrote: > qsynaptics: > QSynaptics aims to help desktop users to configure their synaptics touch > pad that's commonly used in laptops. > > Currently it supports setting the following features: > - pressure sensitivity: adjust how strong you have to press your pad to > create events > - tapping: adjustable tapping delay and disengageable tapping > - smart tapping: switches off mouse pad for an certain delay after an > keyboard event has occured > - mouse button emulation: mapping of multifinger taps to certain mouse button > - circular scrolling: enable or disable circular scrolling and adjusting the > speed, configuring sensitive edges/corner > > SPEC: http://home.bawue.net/~ixs/qsynaptics/qsynaptics.spec > SRPM: http://home.bawue.net/~ixs/qsynaptics/qsynaptics-0.21-1.src.rpm > > Don't you want to be packaging ksynaptics-0.2.0? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From andreas at bawue.net Thu Jul 28 20:09:09 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 28 Jul 2005 22:09:09 +0200 (CEST) Subject: qsynaptics In-Reply-To: <42E93519.3010600@cora.nwra.com> References: <42E93519.3010600@cora.nwra.com> Message-ID: On Thu, 28 Jul 2005, Orion Poplawski wrote: > Don't you want to be packaging ksynaptics-0.2.0? I could package ksynaptics as well. But the only difference between ksynaptics and qsynaptics is that k* does integrate with the kde system, while q* is a stand alone application. Featurewise they are exactly the same. Thus k* is maybe not the right choice for gnome users. but hey, if there's demand, I'll happily package ksynaptics as well. bye, andreas From jspaleta at gmail.com Thu Jul 28 20:10:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 16:10:32 -0400 Subject: Request for review: glpk In-Reply-To: <42E63D65.8040508@ieee.org> References: <42E63D65.8040508@ieee.org> Message-ID: <604aa791050728131017a7a0d9@mail.gmail.com> On 7/26/05, Quentin Spencer wrote: > My SRPM can be found here: > http://webpages.charter.net/qspencer/octave/glpk-4.8-1.src.rpm I seem to be having a hard time pulling this down from the listed url. Do you have an alternative location you can place this? -jef From qspencer at ieee.org Thu Jul 28 20:41:58 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 28 Jul 2005 15:41:58 -0500 Subject: Request for review: glpk In-Reply-To: <604aa791050728131017a7a0d9@mail.gmail.com> References: <42E63D65.8040508@ieee.org> <604aa791050728131017a7a0d9@mail.gmail.com> Message-ID: <42E94316.1060800@ieee.org> Jeff Spaleta wrote: >On 7/26/05, Quentin Spencer wrote: > > >>My SRPM can be found here: >>http://webpages.charter.net/qspencer/octave/glpk-4.8-1.src.rpm >> >> > > >I seem to be having a hard time pulling this down from the listed url. >Do you have an alternative location you can place this? > > That's odd. I just tried downloading it and it worked. Anyway, another octave user has hosted some of my RPMs before, so I put this on his FTP server: ftp://coffee.phys.unm.edu/pub/dima/incoming/glpk-4.8-1.src.rpm I hope this works for you. -Quentin From orion at cora.nwra.com Thu Jul 28 21:06:16 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jul 2005 15:06:16 -0600 Subject: New python-matplotlib version in cvs Message-ID: <42E948C8.3000103@cora.nwra.com> I'm noting this because it has been reworked to require/use the separately packaged pytz and python-dateutil packages (which have just been built for devel and FC4) rather than the versions it comes with. If anyone wants to take a look and comment on it, I'd appreciate it. It's in the queue for a FC4 branch soon, and when ready I'll build. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From jspaleta at gmail.com Thu Jul 28 21:09:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 17:09:23 -0400 Subject: Request for review: glpk In-Reply-To: <42E94316.1060800@ieee.org> References: <42E63D65.8040508@ieee.org> <604aa791050728131017a7a0d9@mail.gmail.com> <42E94316.1060800@ieee.org> Message-ID: <604aa7910507281409200c1db5@mail.gmail.com> On 7/28/05, Quentin Spencer wrote: > That's odd. I just tried downloading it and it worked. Anyway, another > octave user has hosted some of my RPMs before, so I put this on his FTP > server: > ftp://coffee.phys.unm.edu/pub/dima/incoming/glpk-4.8-1.src.rpm got it -jef From wart at kobold.org Thu Jul 28 21:29:32 2005 From: wart at kobold.org (Michael Thomas) Date: Thu, 28 Jul 2005 14:29:32 -0700 Subject: Request for review: tcllib Message-ID: <42E94E3C.7030402@kobold.org> ...Still looking for a review on tcllib so that I can request a build. tcllib is an extremely useful collection of script libraries for programming in Tcl. spec and sources have already been imported to CVS, but since it uses a different spec file than what was in FC1, I need an explicit APPROVE before I can request a build. Thanks, --Mike From jspaleta at gmail.com Thu Jul 28 21:32:49 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 17:32:49 -0400 Subject: Request for review: glpk In-Reply-To: <42E63D65.8040508@ieee.org> References: <42E63D65.8040508@ieee.org> Message-ID: <604aa7910507281432173d844f@mail.gmail.com> On 7/26/05, Quentin Spencer wrote: > One note about this package. The upstream sources do not provide for > building shared libraries. The maintainer has seemed somewhat > unresponsive to requests on the mailing list for this (and a lot of > other things), and I don't really have time or interest in maintaining > patches separate from the sources, so for now this is a static-only > library. I have put everything in glpk-devel, with the intention of > creating a glpk package in the future if shared libs are supported. This > library is not likely to be used by many applications, so for now I > don't see this as a problem. The build process is actually building the shared objects... its just not installing them. It shouldn't be too hard to patch the make install control code to actually install the shared objects as well. If i make a patch wll you use it? -jef From qspencer at ieee.org Thu Jul 28 21:36:49 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 28 Jul 2005 16:36:49 -0500 Subject: Request for review: glpk In-Reply-To: <604aa7910507281432173d844f@mail.gmail.com> References: <42E63D65.8040508@ieee.org> <604aa7910507281432173d844f@mail.gmail.com> Message-ID: <42E94FF1.4090903@ieee.org> Jeff Spaleta wrote: >On 7/26/05, Quentin Spencer wrote: > > >>One note about this package. The upstream sources do not provide for >>building shared libraries. The maintainer has seemed somewhat >>unresponsive to requests on the mailing list for this (and a lot of >>other things), and I don't really have time or interest in maintaining >>patches separate from the sources, so for now this is a static-only >>library. I have put everything in glpk-devel, with the intention of >>creating a glpk package in the future if shared libs are supported. This >>library is not likely to be used by many applications, so for now I >>don't see this as a problem. >> >> > > >The build process is actually building the shared objects... its just >not installing them. It shouldn't be too hard to patch the make >install control code to actually install the shared objects as well. >If i make a patch wll you use it? > > Yes. I would love to have shared libs. I just didn't look carefully enough at the build process to see that this was already happening. -Quentin From jamatos at fc.up.pt Thu Jul 28 21:54:25 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 22:54:25 +0100 Subject: Request to edit CVSSyncNeeded In-Reply-To: <20050728201711.65248802.bugs.michael@gmx.net> References: <200507281641.27210.jamatos@fc.up.pt> <200507281851.28363.jamatos@fc.up.pt> <20050728201711.65248802.bugs.michael@gmx.net> Message-ID: <200507282254.25565.jamatos@fc.up.pt> On Thursday 28 July 2005 19:17, Michael Schwendt wrote: > > Would be an idea, since you would be the only one to use a different > account name. ;) :-) > http://fedoraproject.org/wiki/UserPreferences > says: "(Use FirstnameLastname)" > > "It is best to choose a WikiName (like FirstnameLastname) as username > to get your changes and signatures link back to your WikiHomepage." OK, JoseMatos my wiki name is. :-) Now, please, can I have write access to CVSSyncNeeded? :-) -- Jos? Ab?lio Matos From jamatos at fc.up.pt Thu Jul 28 22:10:11 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 28 Jul 2005 23:10:11 +0100 Subject: New python-matplotlib version in cvs In-Reply-To: <42E948C8.3000103@cora.nwra.com> References: <42E948C8.3000103@cora.nwra.com> Message-ID: <200507282310.12004.jamatos@fc.up.pt> On Thursday 28 July 2005 22:06, Orion Poplawski wrote: > If anyone wants to take a look and comment on it, I'd appreciate it. Notice that you are using not escaped sequences in the %changelog: > * Fri Jul 01 2005 Orion Poplawski 0.82-3 > - Use %{python_sitearch} here, if you really want to do it this way it should be %% > * Thu Jun 30 2005 Orion Poplawski 0.82-2 > - Rename to python-matplotlib > - Remove unneeded Requires: python > - Add private directories to %files as well as here. -- Jos? Ab?lio Matos From bugs.michael at gmx.net Thu Jul 28 22:42:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Jul 2005 00:42:43 +0200 Subject: Request to edit CVSSyncNeeded In-Reply-To: <200507282254.25565.jamatos@fc.up.pt> References: <200507281641.27210.jamatos@fc.up.pt> <200507281851.28363.jamatos@fc.up.pt> <20050728201711.65248802.bugs.michael@gmx.net> <200507282254.25565.jamatos@fc.up.pt> Message-ID: <20050729004243.1954f76e.bugs.michael@gmx.net> On Thu, 28 Jul 2005 22:54:25 +0100, Jose' Matos wrote: > OK, JoseMatos my wiki name is. :-) > > Now, please, can I have write access to CVSSyncNeeded? :-) > Done. From buildsys at fedoraproject.org Thu Jul 28 22:40:42 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jul 2005 18:40:42 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050728224042.7F27E7FE4@extras64> Packages built and released for Fedora Extras 3: 6 leafpad-0.8.3-1.fc3 libcddb-1.2.0-2.fc3 libcddb-1.2.0-3.fc3 libcdio-0.75-3.fc3 notecase-1.0.0-1.fc3 wesnoth-0.9.4-1.fc3 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 Thu Jul 28 22:43:07 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jul 2005 18:43:07 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050728224307.98CDF7FE4@extras64> Packages built and released for Fedora Extras 4: 6 contact-lookup-applet-0.13-1.fc4 leafpad-0.8.3-1.fc4 libcddb-1.2.0-3.fc4 pytz-2005i-2.fc4 splint-3.1.1-10.fc4 wesnoth-0.9.4-1.fc4 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 Thu Jul 28 22:43:56 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jul 2005 18:43:56 -0400 (EDT) Subject: Fedora Extras 5 Package Build Report Message-ID: <20050728224356.9DAFA7FE4@extras64> Packages built and released for Fedora Extras 5: 3 python-dateutil-1.0-1.fc5 pytz-2005i-2.fc5 splint-3.1.1-10.fc5 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 Thu Jul 28 22:44:12 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jul 2005 18:44:12 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050728224412.A826B7FE4@extras64> Packages built and released for Fedora Extras development: 1 splint-3.1.1-10.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From orion at cora.nwra.com Thu Jul 28 23:04:06 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jul 2005 17:04:06 -0600 Subject: New python-matplotlib version in cvs In-Reply-To: <200507282310.12004.jamatos@fc.up.pt> References: <42E948C8.3000103@cora.nwra.com> <200507282310.12004.jamatos@fc.up.pt> Message-ID: <42E96466.3000201@cora.nwra.com> Jose' Matos wrote: > On Thursday 28 July 2005 22:06, Orion Poplawski wrote: > >>If anyone wants to take a look and comment on it, I'd appreciate it. > > > Notice that you are using not escaped sequences in the %changelog: > > >>* Fri Jul 01 2005 Orion Poplawski 0.82-3 >>- Use %{python_sitearch} > > > here, if you really want to do it this way it should be %% > Ah, never realized this was parsed... > >>* Thu Jun 30 2005 Orion Poplawski 0.82-2 >>- Rename to python-matplotlib >>- Remove unneeded Requires: python >>- Add private directories to %files > > > as well as here. > Seems okay at the moment because %files isn't a macro. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From alex at dalloz.de Thu Jul 28 23:42:03 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Fri, 29 Jul 2005 01:42:03 +0200 Subject: Request for review: lzo2 In-Reply-To: <1122566283.5381.30.camel@ignacio.lan> References: <1122561382.3683.115.camel@serendipity.dogma.lan> <1122564109.5381.27.camel@ignacio.lan> <1122564107.2851.42.camel@laurel.intra.city-fan.org> <1122566283.5381.30.camel@ignacio.lan> Message-ID: <1122594123.3683.206.camel@serendipity.dogma.lan> Am Do, den 28.07.2005 schrieb Ignacio Vazquez-Abrams um 17:58: > On Thu, 2005-07-28 at 16:21 +0100, Paul Howarth wrote: > > On Thu, 2005-07-28 at 11:21 -0400, Ignacio Vazquez-Abrams wrote: > > > On Thu, 2005-07-28 at 16:36 +0200, Alexander Dalloz wrote: > > > > http://www.uni-x.org/review/lzo2.spec > > > > > > - Erase the .la file instead of using %exclude > > > > Why? > > On Thu, 2005-07-28 at 17:26 +0200, Alexander Dalloz wrote: > > I have no problem to do so. Would be kind if you could explain me why > > the "%exclude" is wrong. It is the same as used in the lzo-1.08 Extras > > package spec. > > It messes up the package's metadata. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89661 Ignacio, thank you for that information. Curiously I do not see a difference whether I "%exclude" the .la file in %files (-1 release) or whether I rm it in %install (-2 release): $ ~/rpmsizetest.sh lzo2-2.01-1.i386.rpm * 143201 143185 lzo2-2.01-1.i386.rpm $ ~/rpmsizetest.sh lzo2-2.01-2.i386.rpm * 143201 143185 lzo2-2.01-2.i386.rpm Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From tcallawa at redhat.com Fri Jul 29 00:17:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 28 Jul 2005 19:17:25 -0500 Subject: WINE In-Reply-To: <42D836C5.9060306@n-man.com> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> Message-ID: <1122596245.2775.9.camel@localhost.localdomain> On Fri, 2005-07-15 at 17:20 -0500, Patrick Barnes wrote: > The included objects are entirely from-scratch implementations of > Microsoft's DLLs, but just because they don't directly violate > copyrights doesn't mean they're in the clear. This is really something > you should run past RH Legal. Patents are likely to be the bigger > issue. I can't specifically name any conflicts raised so far, but then, > Mono hasn't had any action taken against it either. We already know > Microsoft has a large number of patents covering their technologies, and > purely-original code isn't safe from that threat. After talking with several people, I think we're going to let wine live in livna. The most pressing reason is that for good 3d support, wine needs to be compiled against the NVIDIA GL bits, since they're the fastest GL implementation for Linux. Until a fast open source GL implementation for Linux is released, this will keep wine in livna. If/when the GL issue is resolved, we'll then revisit wine for FE inclusion. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 29 03:01:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 28 Jul 2005 22:01:39 -0500 Subject: Request for review: alleyoop In-Reply-To: <1122518514.4206.0.camel@ignacio.lan> References: <1122517062.2645.21.camel@localhost.localdomain> <42E844B9.3040003@redhat.com> <1122518514.4206.0.camel@ignacio.lan> Message-ID: <1122606099.2775.41.camel@localhost.localdomain> On Wed, 2005-07-27 at 22:41 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-07-27 at 16:36 -1000, Warren Togami wrote: > > Tom 'spot' Callaway wrote: > > > Alleyoop is a graphical front-end to the increasingly popular Valgrind > > > memory checker for x86 GNU/ Linux using the Gtk+ widget set and other > > > GNOME libraries for the X-Windows environment. > > > > > > Small, and simple. Tested on x86 (FC4). > > > > > > SRPM: > > > http://www.auroralinux.org/people/spot/review/alleyoop-0.9.0-1.src.rpm > > > SPEC: http://www.auroralinux.org/people/spot/review/alleyoop.spec > > > > > > > ExclusiveArch: x86 x86_64 > > Is 'x86' a valid arch? Usually you see the macro that expands to all of > > the ix86 archs. I can't remember what that is arch off hand. > > %{ix86} Yeah. Thats a dumb typo on my part. Fixed in -2: SRPM: http://www.auroralinux.org/people/spot/review/alleyoop-0.9.0-2.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/alleyoop.spec Please review. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Fri Jul 29 03:03:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 23:03:18 -0400 Subject: Request for review: lzo2 In-Reply-To: <1122594123.3683.206.camel@serendipity.dogma.lan> References: <1122561382.3683.115.camel@serendipity.dogma.lan> <1122564109.5381.27.camel@ignacio.lan> <1122564107.2851.42.camel@laurel.intra.city-fan.org> <1122566283.5381.30.camel@ignacio.lan> <1122594123.3683.206.camel@serendipity.dogma.lan> Message-ID: <1122606198.4388.1.camel@ignacio.lan> On Fri, 2005-07-29 at 01:42 +0200, Alexander Dalloz wrote: > Am Do, den 28.07.2005 schrieb Ignacio Vazquez-Abrams um 17:58: > > On Thu, 2005-07-28 at 17:26 +0200, Alexander Dalloz wrote: > > > I have no problem to do so. Would be kind if you could explain me why > > > the "%exclude" is wrong. It is the same as used in the lzo-1.08 Extras > > > package spec. > > > > It messes up the package's metadata. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89661 > > Ignacio, > > thank you for that information. Curiously I do not see a difference > whether I "%exclude" the .la file in %files (-1 release) or whether I rm > it in %install (-2 release): > > $ ~/rpmsizetest.sh lzo2-2.01-1.i386.rpm > * 143201 143185 lzo2-2.01-1.i386.rpm > > $ ~/rpmsizetest.sh lzo2-2.01-2.i386.rpm > * 143201 143185 lzo2-2.01-2.i386.rpm *shrug* I can only report information I'm given. If your findings refute that then so be it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Fri Jul 29 03:05:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 28 Jul 2005 22:05:06 -0500 Subject: Request for review: gxemul Message-ID: <1122606307.2775.46.camel@localhost.localdomain> GXemul is an experimental instruction-level machine emulator. It can be used to run binary code for (among others) MIPS-based machines, regardless of host platform. Several emulation modes are available. For some modes, processors and surrounding hardware components are emulated well enough to let unmodified operating systems (e.g. NetBSD) run as if they were running on a real machine. This one builds and packages so fast, if you go to refill your coffee, you may miss it. Its quite small. :) SRPM: http://www.auroralinux.org/people/spot/review/gxemul-0.3.4-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/gxemul.spec Thanks in advance, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Fri Jul 29 03:29:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Jul 2005 23:29:02 -0400 Subject: Request for review: lzo2 In-Reply-To: <1122561382.3683.115.camel@serendipity.dogma.lan> References: <1122561382.3683.115.camel@serendipity.dogma.lan> Message-ID: <1122607742.4388.3.camel@ignacio.lan> On Thu, 2005-07-28 at 16:36 +0200, Alexander Dalloz wrote: > http://www.uni-x.org/review/lzo2.spec > http://www.uni-x.org/review/lzo2-2.01-1.src.rpm If no one else pipes up about the %exclude issue then consider this one approved. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jspaleta at gmail.com Fri Jul 29 03:57:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 23:57:40 -0400 Subject: Request for review: gxemul In-Reply-To: <1122606307.2775.46.camel@localhost.localdomain> References: <1122606307.2775.46.camel@localhost.localdomain> Message-ID: <604aa791050728205721a7910d@mail.gmail.com> On 7/28/05, Tom 'spot' Callaway wrote: > SRPM: > http://www.auroralinux.org/people/spot/review/gxemul-0.3.4-1.src.rpm > SPEC: > http://www.auroralinux.org/people/spot/review/gxemul.spec good - builds in mock for fc4 x86 good - rpmlint gxemul-0.3.4-1.fc4.i386.rpm paases with expected disttag warning: W: gxemul incoherent-version-in-changelog 0.3.4-1 0.3.4-1.fc4 good - follows naming guideline good - license is included in docs good - source matches upstream source good - no unowned directories created no locales to deal with. no scriptlets by definition are sane scriptlets I give you tentative approval. And I'll post to the commits list with the required approval post no later than before I go to work tomorrow barring any earch shattering events. Any reason why you didn't just use the %configure macro? -jef From buildsys at fedoraproject.org Fri Jul 29 05:37:57 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jul 2005 01:37:57 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050729053757.E150A7FE4@extras64> Packages built and released for Fedora Extras 3: 1 mercurial-0.6b-1.fc3 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From rc040203 at freenet.de Fri Jul 29 05:39:19 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 07:39:19 +0200 Subject: WINE In-Reply-To: <1122596245.2775.9.camel@localhost.localdomain> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> Message-ID: <1122615559.4941.60.camel@mccallum.corsepiu.local> On Thu, 2005-07-28 at 19:17 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-15 at 17:20 -0500, Patrick Barnes wrote: > After talking with several people, I think we're going to let wine live > in livna. The most pressing reason is that for good 3d support, wine > needs to be compiled against the NVIDIA GL bits, since they're the > fastest GL implementation for Linux. Until a fast open source GL > implementation for Linux is released, this will keep wine in livna. > > If/when the GL issue is resolved, we'll then revisit wine for FE > inclusion. What you say here doesn't make much sense, because GL support in Linux is implemented via shared libraries. I.e. you normally compile against Mesa-LibGL's headers/API and use an arbitrary libGL.so.1 at run-time. I.e. the GL spead-up provided by NVidia's GL is a run-time feature, not a built-time dependency. Ralf From buildsys at fedoraproject.org Fri Jul 29 05:42:45 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jul 2005 01:42:45 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050729054245.5FE607FE4@extras64> Packages built and released for Fedora Extras 4: 2 mercurial-0.6b-1.fc4 seahorse-0.7.9-1.fc4 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 Jul 29 05:58:51 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jul 2005 01:58:51 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050729055851.3EC087FE4@extras64> Packages built and released for Fedora Extras development: 4 abiword-2.2.9-1 gaim-meanwhile-1.2.4-2.fc5 mercurial-0.6b-1.fc5 seahorse-0.7.9-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at phy.duke.edu Fri Jul 29 06:09:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 02:09:05 -0400 Subject: repomanage'ing extras development Message-ID: <1122617345.2521.8.camel@cutter> Anyone have any objections if I run repomanage -o over top of extras development to purge out old packages? it's getting sorta unnecessarily big. -sv From caillon at redhat.com Fri Jul 29 06:52:22 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 29 Jul 2005 02:52:22 -0400 Subject: Package seeking review: libsvg Message-ID: <42E9D226.7070202@redhat.com> http://people.redhat.com/caillon/RPMS/rawhide/libsvg.spec http://people.redhat.com/caillon/RPMS/rawhide/libsvg-0.1.4-1.src.rpm From caillon at redhat.com Fri Jul 29 06:52:24 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 29 Jul 2005 02:52:24 -0400 Subject: Package seeking review: libsvg-cairo Message-ID: <42E9D228.4060508@redhat.com> http://people.redhat.com/caillon/RPMS/rawhide/libsvg-cairo.spec http://people.redhat.com/caillon/RPMS/rawhide/libsvg-cairo-0.1.6-1.src.rpm From caillon at redhat.com Fri Jul 29 06:52:27 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 29 Jul 2005 02:52:27 -0400 Subject: Package seeking review: svg2png Message-ID: <42E9D22B.3030104@redhat.com> http://people.redhat.com/caillon/RPMS/rawhide/svg2png.spec http://people.redhat.com/caillon/RPMS/rawhide/svg2png-0.1.3-1.src.rpm From ivazquez at ivazquez.net Fri Jul 29 07:05:24 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Jul 2005 03:05:24 -0400 Subject: Package seeking review: libsvg In-Reply-To: <42E9D226.7070202@redhat.com> References: <42E9D226.7070202@redhat.com> Message-ID: <1122620724.302.0.camel@ignacio.lan> On Fri, 2005-07-29 at 02:52 -0400, Christopher Aillon wrote: > http://people.redhat.com/caillon/RPMS/rawhide/libsvg.spec - Remove the BR of pkgconfig - Remove the explicit Requires - Remove the .la file -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ivazquez at ivazquez.net Fri Jul 29 07:06:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Jul 2005 03:06:35 -0400 Subject: Package seeking review: libsvg-cairo In-Reply-To: <42E9D228.4060508@redhat.com> References: <42E9D228.4060508@redhat.com> Message-ID: <1122620795.302.2.camel@ignacio.lan> On Fri, 2005-07-29 at 02:52 -0400, Christopher Aillon wrote: > http://people.redhat.com/caillon/RPMS/rawhide/libsvg-cairo.spec - Remove the BR of pkgconfig - Remove the explicit Requires - Remove the .la file -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ivazquez at ivazquez.net Fri Jul 29 07:07:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Jul 2005 03:07:27 -0400 Subject: Package seeking review: svg2png In-Reply-To: <42E9D22B.3030104@redhat.com> References: <42E9D22B.3030104@redhat.com> Message-ID: <1122620847.302.4.camel@ignacio.lan> On Fri, 2005-07-29 at 02:52 -0400, Christopher Aillon wrote: > http://people.redhat.com/caillon/RPMS/rawhide/svg2png.spec - Remove the BR of pkgconfig -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 rc040203 at freenet.de Fri Jul 29 07:20:37 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 09:20:37 +0200 Subject: Package seeking review: libsvg In-Reply-To: <42E9D226.7070202@redhat.com> References: <42E9D226.7070202@redhat.com> Message-ID: <1122621637.4941.73.camel@mccallum.corsepiu.local> On Fri, 2005-07-29 at 02:52 -0400, Christopher Aillon wrote: > http://people.redhat.com/caillon/RPMS/rawhide/libsvg.spec > http://people.redhat.com/caillon/RPMS/rawhide/libsvg-0.1.4-1.src.rpm Basically OK, with a few minor gripes: - Doc files in /usr/share/*/* are executable. They should be non-executable. - I would recommend to disable building static libs %configure --disable-static o You are shipping libtool archives. Some people around here feel religious about it and will want you to not ship them - I consider shipping *.la's to be correct ;) - The base-package's Requires: libxml2 >= %{libxml2_version} probably is not necessary. - rpmlint complains about the dot in the summary: W: libsvg summary-ended-with-dot A generic SVG library. o The devel package ships pkgconfig files. It might be worth considering to let this package 'BR: pkgconfig'. Ralf From rc040203 at freenet.de Fri Jul 29 07:27:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 09:27:22 +0200 Subject: Package seeking review: libsvg In-Reply-To: <1122621637.4941.73.camel@mccallum.corsepiu.local> References: <42E9D226.7070202@redhat.com> <1122621637.4941.73.camel@mccallum.corsepiu.local> Message-ID: <1122622043.4941.76.camel@mccallum.corsepiu.local> On Fri, 2005-07-29 at 09:20 +0200, Ralf Corsepius wrote: > On Fri, 2005-07-29 at 02:52 -0400, Christopher Aillon wrote: > > http://people.redhat.com/caillon/RPMS/rawhide/libsvg.spec > > http://people.redhat.com/caillon/RPMS/rawhide/libsvg-0.1.4-1.src.rpm > > Basically OK, with a few minor gripes: > - Doc files in /usr/share/*/* are executable. They should be > non-executable. > > - I would recommend to disable building static libs > %configure --disable-static > > o You are shipping libtool archives. > Some people around here feel religious about it and will want you to not > ship them - I consider shipping *.la's to be correct ;) > > - The base-package's > Requires: libxml2 >= %{libxml2_version} > probably is not necessary. > > - rpmlint complains about the dot in the summary: > W: libsvg summary-ended-with-dot A generic SVG library. > > o The devel package ships pkgconfig files. It might be worth considering > to let this package 'BR: pkgconfig'. Sorry, braino, I meant "Requires: pkgconfig" Ralf From leet at leenx.co.za Fri Jul 29 08:11:07 2005 From: leet at leenx.co.za (C.Lee Taylor) Date: Fri, 29 Jul 2005 10:11:07 +0200 Subject: New clamav-milter problem ... In-Reply-To: <20050729065232.AC52473894@hormel.redhat.com> References: <20050729065232.AC52473894@hormel.redhat.com> Message-ID: <42E9E49B.5090900@leenx.co.za> Greetings ... I think there might be a problem with clamav-milter-0.86.2-2.fc4, if I try to start it with any option change to /etc/sysconfig/clamav-milter or start the problem by it's self, I get the following error ... Shutting down clamav-milter: [FAILED] Starting clamav-milter: /usr/sbin/clamav-milter: --timeout must not be given if --external is not given [FAILED] Force downgrade to clamav-milter-0.86.1-2.fc4, and now clamav-milter starts fine and my mail is working again ... This be a package bug or me ... Thanks Mailed Lee From oliver at linux-kernel.at Fri Jul 29 08:24:33 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Jul 2005 10:24:33 +0200 Subject: New clamav-milter problem ... In-Reply-To: <42E9E49B.5090900@leenx.co.za> References: <20050729065232.AC52473894@hormel.redhat.com> <42E9E49B.5090900@leenx.co.za> Message-ID: <42E9E7C1.3030709@linux-kernel.at> On 07/29/2005 10:11 AM, C.Lee Taylor wrote: > Greetings ... > > I think there might be a problem with clamav-milter-0.86.2-2.fc4, if > I try to start it with any option change to /etc/sysconfig/clamav-milter > or start the problem by it's self, I get the following error ... > > Shutting down clamav-milter: [FAILED] > Starting clamav-milter: /usr/sbin/clamav-milter: --timeout must not be > given if --external is not given > [FAILED] > > Force downgrade to clamav-milter-0.86.1-2.fc4, and now clamav-milter > starts fine and my mail is working again ... This be a package bug or > me ... Add --timeout=0 to /etc/sysconfig/clamav-milter and it will work. It's not really a package problem, but it can be fixed by the package. :-) Best, Oliver From oliver at linux-kernel.at Fri Jul 29 08:48:52 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Jul 2005 10:48:52 +0200 Subject: [Fwd: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development] Message-ID: <42E9ED74.7010701@linux-kernel.at> Oops, what's going on here? Best, Oliver -------- Original Message -------- Subject: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development Date: Fri, 29 Jul 2005 04:43:10 -0400 (EDT) From: buildsys at fedoraproject.org To: oliver at linux-kernel.at Job failed on arch i386 Build logs may be found at http://buildsys.fedoraproject.org/logs//development/129-bwm-ng-0.5-5.fc5/ ------------------------------------------------- Dependency Installed: MAKEDEV.i386 0:3.19-1 SysVinit.i386 0:2.85-40 audit-libs.i386 0:0.9.19-2 basesystem.noarch 0:8.0-5 beecrypt.i386 0:4.1.2-8 bzip2-libs.i386 0:1.0.2-16 cpp.i386 0:4.0.1-4 cracklib.i386 0:2.8.3-1 cracklib-dicts.i386 0:2.8.3-1 db4.i386 0:4.3.27-4 device-mapper.i386 0:1.01.03-1.0 e2fsprogs.i386 0:1.37-4 elfutils-libelf.i386 0:0.110-1 ethtool.i386 0:3-1 expat.i386 0:1.95.8-6 file.i386 0:4.14-2 filesystem.i386 0:2.3.4-1 gawk.i386 0:3.1.4-5.2 gdbm.i386 0:1.8.0-25 glib2.i386 0:2.7.4-1 glibc-common.i386 0:2.3.90-6 glibc-devel.i386 0:2.3.90-6 glibc-headers.i386 0:2.3.90-6 glibc-kernheaders.i386 0:2.4-9.1.95 grep.i386 0:2.5.1-50 hotplug.i386 3:2004_09_23-9 hwdata.noarch 0:0.162-1 info.i386 0:4.8-6 iproute.i386 0:2.6.11-2 iputils.i386 0:20020927-24 kernel.i686 0:2.6.12-1.1437_FC5 krb5-libs.i386 0:1.4.1-6 less.i386 0:382-7 libacl.i386 0:2.2.23-8 libattr.i386 0:2.4.16-5 libgcc.i386 0:4.0.1-4 libselinux.i386 0:1.24.2-1 libsepol.i386 0:1.7.6-2 libstdc++.i386 0:4.0.1-4 li bstdc++-devel.i386 0:4.0.1-4 libtermcap.i386 0:2.0.8-41 libxml2.i386 0:2.6.20-1 libxml2-python.i386 0:2.6.20-1 lvm2.i386 0:2.01.13-1.0 m4.i386 0:1.4.3-1 mingetty.i386 0:1.07-5 mkinitrd.i386 0:4.2.18-1 mktemp.i386 3:1.5-23 module-init-tools.i386 0:3.2-0.pre7.2 ncurses.i386 0:5.4-17 neon.i386 0:0.24.7-6 net-tools.i386 0:1.60-55 openssh.i386 0:4.1p1-4 openssl.i686 0:0.9.7f-7 pam.i386 0:0.80-4 pcre.i386 0:5.0-4 perl.i386 3:5.8.6-15 perl-Compress-Zlib.i386 0:1.34-2 perl-Filter.i386 0:1.30-7 perl-HTML-Parser.i386 0:3.45-1 perl-HTML-Tagset.noarch 0:3.04-1 perl-URI.noarch 0:1.35-2 perl-XML-NamespaceSupport.noarch 0:1.08-7 perl-libwww-perl.noarch 0:5.803-2 popt.i386 0:1.10.2-3 procps.i386 0:3.2.5-6.3 psmisc.i386 0:21.5-4 readline.i386 0:5.0-3 rpm-libs.i386 0:4.4.2-3 sed.i386 0:4.1.4-1 setup.noarch 0:2.5.46-1 shadow-utils.i386 2:4.0.7-9 sqlite.i386 0:3.2.2-1 sysklogd.i386 0:1.4.1-30 tcp_wrappers.i386 0:7.6-39 termcap.noarch 1:5.4-4 tzdata.noarch 0:2005k-2 util-linux.i386 0:2.12p-10 zl ib.i386 0:1.2.2.2-5 ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts /sbin/runuser -c 'rpm -Uvh --nodeps /builddir/build/originals/bwm-ng-0.5-5.fc5.src.rpm' mockbuild bwm-ng ################################################## warning: Could not canonicalize hostname: hammer1.fedora.redhat.com Building target platforms: i386 Building for target i386 Wrote: /builddir/build/SRPMS/bwm-ng-0.5-5.fc5.src.rpm ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root resolvedep 'libstatgrab-devel' 'ncurses-devel' 0:libstatgrab-devel-0.11.1-3.fc5.x86_64 0:ncurses-devel-5.4-17.i386 0:libstatgrab-devel-0.11.1-3.fc5.x86_64 0:ncurses-devel-5.4-17.i386 ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root install 'libstatgrab-devel' 'ncurses-devel' Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by package libstatgrab Error: Missing Dependency: libc.so.6(GLIBC_2.3)(64bit) is needed by package libstatgrab Error: Missing Dependency: libc.so.6()(64bit) is needed by package libstatgrab Error: Missing Dependency: libc.so.6(GLIBC_2.3.4)(64bit) is needed by package libstatgrab Cleaning up... Done. From paul at city-fan.org Fri Jul 29 08:59:14 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 29 Jul 2005 09:59:14 +0100 Subject: [Fwd: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development] In-Reply-To: <42E9ED74.7010701@linux-kernel.at> References: <42E9ED74.7010701@linux-kernel.at> Message-ID: <42E9EFE2.40605@city-fan.org> Oliver Falk wrote: > Oops, what's going on here? > > Best, > Oliver > > -------- Original Message -------- > Subject: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development > Date: Fri, 29 Jul 2005 04:43:10 -0400 (EDT) > From: buildsys at fedoraproject.org > To: oliver at linux-kernel.at > > Job failed on arch i386 > > > Build logs may be found at > http://buildsys.fedoraproject.org/logs//development/129-bwm-ng-0.5-5.fc5/ > > > ------------------------------------------------- > > Dependency Installed: MAKEDEV.i386 0:3.19-1 SysVinit.i386 0:2.85-40 > audit-libs.i386 0:0.9.19-2 basesystem.noarch 0:8.0-5 beecrypt.i386 > 0:4.1.2-8 bzip2-libs.i386 0:1.0.2-16 cpp.i386 0:4.0.1-4 cracklib.i386 > 0:2.8.3-1 cracklib-dicts.i386 0:2.8.3-1 db4.i386 0:4.3.27-4 > device-mapper.i386 0:1.01.03-1.0 e2fsprogs.i386 0:1.37-4 > elfutils-libelf.i386 0:0.110-1 ethtool.i386 0:3-1 expat.i386 0:1.95.8-6 > file.i386 0:4.14-2 filesystem.i386 0:2.3.4-1 gawk.i386 0:3.1.4-5.2 > gdbm.i386 0:1.8.0-25 glib2.i386 0:2.7.4-1 glibc-common.i386 0:2.3.90-6 > glibc-devel.i386 0:2.3.90-6 glibc-headers.i386 0:2.3.90-6 > glibc-kernheaders.i386 0:2.4-9.1.95 grep.i386 0:2.5.1-50 hotplug.i386 > 3:2004_09_23-9 hwdata.noarch 0:0.162-1 info.i386 0:4.8-6 iproute.i386 > 0:2.6.11-2 iputils.i386 0:20020927-24 kernel.i686 0:2.6.12-1.1437_FC5 > krb5-libs.i386 0:1.4.1-6 less.i386 0:382-7 libacl.i386 0:2.2.23-8 > libattr.i386 0:2.4.16-5 libgcc.i386 0:4.0.1-4 libselinux.i386 0:1.24.2-1 > libsepol.i386 0:1.7.6-2 libstdc++.i386 0:4.0.1-4 li > bstdc++-devel.i386 0:4.0.1-4 libtermcap.i386 0:2.0.8-41 libxml2.i386 > 0:2.6.20-1 libxml2-python.i386 0:2.6.20-1 lvm2.i386 0:2.01.13-1.0 > m4.i386 0:1.4.3-1 mingetty.i386 0:1.07-5 mkinitrd.i386 0:4.2.18-1 > mktemp.i386 3:1.5-23 module-init-tools.i386 0:3.2-0.pre7.2 ncurses.i386 > 0:5.4-17 neon.i386 0:0.24.7-6 net-tools.i386 0:1.60-55 openssh.i386 > 0:4.1p1-4 openssl.i686 0:0.9.7f-7 pam.i386 0:0.80-4 pcre.i386 0:5.0-4 > perl.i386 3:5.8.6-15 perl-Compress-Zlib.i386 0:1.34-2 perl-Filter.i386 > 0:1.30-7 perl-HTML-Parser.i386 0:3.45-1 perl-HTML-Tagset.noarch 0:3.04-1 > perl-URI.noarch 0:1.35-2 perl-XML-NamespaceSupport.noarch 0:1.08-7 > perl-libwww-perl.noarch 0:5.803-2 popt.i386 0:1.10.2-3 procps.i386 > 0:3.2.5-6.3 psmisc.i386 0:21.5-4 readline.i386 0:5.0-3 rpm-libs.i386 > 0:4.4.2-3 sed.i386 0:4.1.4-1 setup.noarch 0:2.5.46-1 shadow-utils.i386 > 2:4.0.7-9 sqlite.i386 0:3.2.2-1 sysklogd.i386 0:1.4.1-30 > tcp_wrappers.i386 0:7.6-39 termcap.noarch 1:5.4-4 tzdata.noarch > 0:2005k-2 util-linux.i386 0:2.12p-10 zl > ib.i386 0:1.2.2.2-5 > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc > > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts > > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc > > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts > > /sbin/runuser -c 'rpm -Uvh --nodeps > /builddir/build/originals/bwm-ng-0.5-5.fc5.src.rpm' mockbuild > bwm-ng ################################################## > warning: Could not canonicalize hostname: hammer1.fedora.redhat.com > Building target platforms: i386 > Building for target i386 > Wrote: /builddir/build/SRPMS/bwm-ng-0.5-5.fc5.src.rpm > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc > > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts > > /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root > resolvedep 'libstatgrab-devel' 'ncurses-devel' > 0:libstatgrab-devel-0.11.1-3.fc5.x86_64 > 0:ncurses-devel-5.4-17.i386 > 0:libstatgrab-devel-0.11.1-3.fc5.x86_64 > 0:ncurses-devel-5.4-17.i386 > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc > > ensuring dir > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts > > /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root > install 'libstatgrab-devel' 'ncurses-devel' > Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by > package libstatgrab > Error: Missing Dependency: libc.so.6(GLIBC_2.3)(64bit) is needed by > package libstatgrab > Error: Missing Dependency: libc.so.6()(64bit) is needed by package > libstatgrab > Error: Missing Dependency: libc.so.6(GLIBC_2.3.4)(64bit) is needed by > package libstatgrab > Cleaning up... > Done. The i386 build system has pulled in an x86_64 package for libstatgrab-devel, for reasons best known to itself. Time to head for bugzilla methinks. Paul. From oliver at linux-kernel.at Fri Jul 29 09:04:16 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Jul 2005 11:04:16 +0200 Subject: [Fwd: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development] In-Reply-To: <42E9EFE2.40605@city-fan.org> References: <42E9ED74.7010701@linux-kernel.at> <42E9EFE2.40605@city-fan.org> Message-ID: <42E9F110.2040506@linux-kernel.at> On 07/29/2005 10:59 AM, Paul Howarth wrote: > Oliver Falk wrote: > >> Oops, what's going on here? >> >> Best, >> Oliver >> >> -------- Original Message -------- >> Subject: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development >> Date: Fri, 29 Jul 2005 04:43:10 -0400 (EDT) >> From: buildsys at fedoraproject.org >> To: oliver at linux-kernel.at >> >> Job failed on arch i386 >> >> >> Build logs may be found at >> http://buildsys.fedoraproject.org/logs//development/129-bwm-ng-0.5-5.fc5/ >> >> >> ------------------------------------------------- >> >> Dependency Installed: MAKEDEV.i386 0:3.19-1 SysVinit.i386 0:2.85-40 >> audit-libs.i386 0:0.9.19-2 basesystem.noarch 0:8.0-5 beecrypt.i386 >> 0:4.1.2-8 bzip2-libs.i386 0:1.0.2-16 cpp.i386 0:4.0.1-4 cracklib.i386 >> 0:2.8.3-1 cracklib-dicts.i386 0:2.8.3-1 db4.i386 0:4.3.27-4 >> device-mapper.i386 0:1.01.03-1.0 e2fsprogs.i386 0:1.37-4 >> elfutils-libelf.i386 0:0.110-1 ethtool.i386 0:3-1 expat.i386 >> 0:1.95.8-6 file.i386 0:4.14-2 filesystem.i386 0:2.3.4-1 gawk.i386 >> 0:3.1.4-5.2 gdbm.i386 0:1.8.0-25 glib2.i386 0:2.7.4-1 >> glibc-common.i386 0:2.3.90-6 glibc-devel.i386 0:2.3.90-6 >> glibc-headers.i386 0:2.3.90-6 glibc-kernheaders.i386 0:2.4-9.1.95 >> grep.i386 0:2.5.1-50 hotplug.i386 3:2004_09_23-9 hwdata.noarch >> 0:0.162-1 info.i386 0:4.8-6 iproute.i386 0:2.6.11-2 iputils.i386 >> 0:20020927-24 kernel.i686 0:2.6.12-1.1437_FC5 krb5-libs.i386 0:1.4.1-6 >> less.i386 0:382-7 libacl.i386 0:2.2.23-8 libattr.i386 0:2.4.16-5 >> libgcc.i386 0:4.0.1-4 libselinux.i386 0:1.24.2-1 libsepol.i386 >> 0:1.7.6-2 libstdc++.i386 0:4.0.1-4 li >> bstdc++-devel.i386 0:4.0.1-4 libtermcap.i386 0:2.0.8-41 libxml2.i386 >> 0:2.6.20-1 libxml2-python.i386 0:2.6.20-1 lvm2.i386 0:2.01.13-1.0 >> m4.i386 0:1.4.3-1 mingetty.i386 0:1.07-5 mkinitrd.i386 0:4.2.18-1 >> mktemp.i386 3:1.5-23 module-init-tools.i386 0:3.2-0.pre7.2 >> ncurses.i386 0:5.4-17 neon.i386 0:0.24.7-6 net-tools.i386 0:1.60-55 >> openssh.i386 0:4.1p1-4 openssl.i686 0:0.9.7f-7 pam.i386 0:0.80-4 >> pcre.i386 0:5.0-4 perl.i386 3:5.8.6-15 perl-Compress-Zlib.i386 >> 0:1.34-2 perl-Filter.i386 0:1.30-7 perl-HTML-Parser.i386 0:3.45-1 >> perl-HTML-Tagset.noarch 0:3.04-1 perl-URI.noarch 0:1.35-2 >> perl-XML-NamespaceSupport.noarch 0:1.08-7 perl-libwww-perl.noarch >> 0:5.803-2 popt.i386 0:1.10.2-3 procps.i386 0:3.2.5-6.3 psmisc.i386 >> 0:21.5-4 readline.i386 0:5.0-3 rpm-libs.i386 0:4.4.2-3 sed.i386 >> 0:4.1.4-1 setup.noarch 0:2.5.46-1 shadow-utils.i386 2:4.0.7-9 >> sqlite.i386 0:3.2.2-1 sysklogd.i386 0:1.4.1-30 tcp_wrappers.i386 >> 0:7.6-39 termcap.noarch 1:5.4-4 tzdata.noarch 0:2005k-2 >> util-linux.i386 0:2.12p-10 zl >> ib.i386 0:1.2.2.2-5 >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc >> >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts >> >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc >> >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts >> >> /sbin/runuser -c 'rpm -Uvh --nodeps >> /builddir/build/originals/bwm-ng-0.5-5.fc5.src.rpm' mockbuild >> bwm-ng ################################################## >> warning: Could not canonicalize hostname: hammer1.fedora.redhat.com >> Building target platforms: i386 >> Building for target i386 >> Wrote: /builddir/build/SRPMS/bwm-ng-0.5-5.fc5.src.rpm >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc >> >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts >> >> /usr/sbin/mock-helper yum --installroot >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root >> resolvedep 'libstatgrab-devel' 'ncurses-devel' >> 0:libstatgrab-devel-0.11.1-3.fc5.x86_64 >> 0:ncurses-devel-5.4-17.i386 >> 0:libstatgrab-devel-0.11.1-3.fc5.x86_64 >> 0:ncurses-devel-5.4-17.i386 >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/proc >> >> ensuring dir >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root/dev/pts >> >> /usr/sbin/mock-helper yum --installroot >> /var/lib/mock/fedora-development-i386-core-200f52d2cf994ddcb6a10f2e34315ced8b17cde3/root >> install 'libstatgrab-devel' 'ncurses-devel' >> Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by >> package libstatgrab >> Error: Missing Dependency: libc.so.6(GLIBC_2.3)(64bit) is needed by >> package libstatgrab >> Error: Missing Dependency: libc.so.6()(64bit) is needed by package >> libstatgrab >> Error: Missing Dependency: libc.so.6(GLIBC_2.3.4)(64bit) is needed by >> package libstatgrab >> Cleaning up... >> Done. > > > The i386 build system has pulled in an x86_64 package for > libstatgrab-devel, for reasons best known to itself. Time to head for > bugzilla methinks. OK, so you are guessing the same as I do. Maybe Seth also has some idea, why this happend... Best, Oliver From dragoran at feuerpokemon.de Fri Jul 29 10:08:21 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 29 Jul 2005 12:08:21 +0200 Subject: Fedora Extras 4 Package Build Report In-Reply-To: <604aa791050728064673817a1f@mail.gmail.com> References: <20050728080028.9025D7FE6@extras64> <42E8CDA4.5070406@feuerpokemon.de> <604aa791050728064673817a1f@mail.gmail.com> Message-ID: <42EA0015.9090006@feuerpokemon.de> Jeff Spaleta wrote: >On 7/28/05, dragoran wrote: > > >>libcddb and libcdio are still broken (don't let me install vcdimager >>from livna or freshrpms): >> >> > >You need to be more careful about what you mean by 'broken' and where >you point the finger. In this case Fedora Extras is no longer broken.. >the libcddb and libcdio packages form a self-consistent set. The >problem is the updated versions include new versions of the libraries >that are incompatible with the older livna and freshrpms packages. >The 'breaking' of depchains across repository boundaries is very very >hard to avoid as long as Fedora Extras continues to use a rolling >release model that allows for updates to include new libraries that >change ABI and API. In this respect Fedora Extras shares some >characteristics with rawhide. >Once you start talking about dependancy problems across any repository >boundary things get really complicated. Core updates on occasion will >'break' Extras packages in a similar fashion until Extras catches up, >more so with Core development. > >Notwithstanding a shift in the rolling policy, there are potential >ways to make it easier for 3rd party repos to catch up before an >ABI/API breaking update is pushed to the consumable FE tree. There >could be a minimal amount of time that new updates sit in a "pending" >repo and 3rd party repos can run scripted runs of repoclosure against >FE and FE-pending as well as their own repos. Runs of repoclosure in >this way would give 3rd party maintainers a headsup about impending >dep chain breakages and give them a finite time to respond with >updates to their packages or to talk with the FE maintainer and work >out another arrangement like providing a compatibility package in FE >if that is the more appropriate solution. > >-jef > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > Hello I thought that the error is in extras because of this: http://www.redhat.com/archives/fedora-devel-list/2005-July/msg00819.html but it seems to be only a abi issue ... I downloaded the src rpm and it builds and installs fine with now. From andreas at bawue.net Fri Jul 29 12:42:01 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 29 Jul 2005 14:42:01 +0200 (CEST) Subject: New package, review needed: icecast Message-ID: Hello, I packaged the current svn branch of icecast from Karl Heyes. His version has some improved functionality over the trunk branch, such as on demand streams, which is nice for leaf sites as data is only streamed if there are actual listeners. icecast: Icecast is a streaming media server which currently supports Ogg Vorbis and MP3 audio streams. It can be used to create an Internet radio station or a privately running jukebox and many things in between. It is very versatile in that new formats can be added relatively easily and supports open standards for commuincation and interaction. SPEC: http://home.bawue.net/~ixs/icecast/icecast.spec SRPM: http://home.bawue.net/~ixs/icecast/icecast-2.2.0kh-1.svn9640.src.rpm If someone could please review that package and approve it. Additionally, there are still some review requests for the following packages outstanding: simgear qsynaptics ddrescue dd_rescue dd_rhelp If you are interested in reviewing one of these packages, please see https://www.redhat.com/archives/fedora-extras-list/2005-July/msg01272.html for more information. thx, andreas From tcallawa at redhat.com Fri Jul 29 13:08:05 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 08:08:05 -0500 Subject: Request for review: gxemul In-Reply-To: <604aa791050728205721a7910d@mail.gmail.com> References: <1122606307.2775.46.camel@localhost.localdomain> <604aa791050728205721a7910d@mail.gmail.com> Message-ID: <1122642485.2775.50.camel@localhost.localdomain> On Thu, 2005-07-28 at 23:57 -0400, Jeff Spaleta wrote: > Any reason why you didn't just use the %configure macro? Because gxemul's configure isn't autoconf generated. The default options, as passed by %configure, cause it to error out. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Jul 29 13:12:48 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 08:12:48 -0500 Subject: WINE In-Reply-To: <1122615559.4941.60.camel@mccallum.corsepiu.local> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> <1122615559.4941.60.camel@mccallum.corsepiu.local> Message-ID: <1122642768.2775.54.camel@localhost.localdomain> On Fri, 2005-07-29 at 07:39 +0200, Ralf Corsepius wrote: > On Thu, 2005-07-28 at 19:17 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2005-07-15 at 17:20 -0500, Patrick Barnes wrote: > > > After talking with several people, I think we're going to let wine live > > in livna. The most pressing reason is that for good 3d support, wine > > needs to be compiled against the NVIDIA GL bits, since they're the > > fastest GL implementation for Linux. Until a fast open source GL > > implementation for Linux is released, this will keep wine in livna. > > > > If/when the GL issue is resolved, we'll then revisit wine for FE > > inclusion. > What you say here doesn't make much sense, because GL support in Linux > is implemented via shared libraries. > > I.e. you normally compile against Mesa-LibGL's headers/API and use an > arbitrary libGL.so.1 at run-time. I.e. the GL spead-up provided by > NVidia's GL is a run-time feature, not a built-time dependency. Umm, ok. :) I've not personally used wine since 2001. I'm just going on what several people told me. If we can compile wine without the NVIDIA proprietary bits, then it should be ok for FE. As to legal review, we can certainly do that, but Red Hat did ship wine in RHL for a good period of time, and it was not dropped for legal issues (afaik), so I think it should be alright. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at phy.duke.edu Fri Jul 29 13:22:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 09:22:30 -0400 Subject: [Fwd: Build Error (Job 129): bwm-ng-0_5-5_fc5 on development] In-Reply-To: <42E9F110.2040506@linux-kernel.at> References: <42E9ED74.7010701@linux-kernel.at> <42E9EFE2.40605@city-fan.org> <42E9F110.2040506@linux-kernel.at> Message-ID: <1122643350.2521.19.camel@cutter> > > The i386 build system has pulled in an x86_64 package for > > libstatgrab-devel, for reasons best known to itself. Time to head for > > bugzilla methinks. > > OK, so you are guessing the same as I do. Maybe Seth also has some idea, > why this happend... > I'm guessing the /etc/rpm/platform file still says x86_64 on the hammer machines and that's playing hell with the arch settings. -sv From fedora at camperquake.de Fri Jul 29 13:27:00 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 29 Jul 2005 15:27:00 +0200 Subject: repomanage'ing extras development In-Reply-To: <1122617345.2521.8.camel@cutter> References: <1122617345.2521.8.camel@cutter> Message-ID: <20050729152700.18fd01c9@nausicaa.camperquake.de> Hi. seth vidal wrote: > Anyone have any objections if I run repomanage -o over top of extras > development to purge out old packages? Can you easily retain the two latest versions instead of just the latest? -- "Shall I tell you what I want? What I really really want?" From thomas at apestaart.org Fri Jul 29 13:36:28 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 29 Jul 2005 15:36:28 +0200 Subject: New package, review needed: icecast In-Reply-To: References: Message-ID: <1122644188.9931.10.camel@thomas.amantes> Hi, > Hello, > > I packaged the current svn branch of icecast from Karl Heyes. His version > has some improved functionality over the trunk branch, such as on demand > streams, which is nice for leaf sites as data is only streamed if there > are actual listeners. If you're going to package a branch, you should make a separate package completely. If upstream doesn't feel it should be released as the main branch, there is a reason. You could do this by using transform-name for configure, or by making a package with a different name that conflicts with a package named "icecast". Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Now I find myself redeemed 'cos no one's seen the bad in me or been where I've been <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From leet at leenx.co.za Fri Jul 29 13:49:09 2005 From: leet at leenx.co.za (C.Lee Taylor) Date: Fri, 29 Jul 2005 15:49:09 +0200 Subject: New clamav-milter problem ... In-Reply-To: <20050729132005.DB67E73898@hormel.redhat.com> References: <20050729132005.DB67E73898@hormel.redhat.com> Message-ID: <42EA33D5.10403@leenx.co.za> Greetings ... Thanks Oliver for your quick response ... >> Starting clamav-milter: /usr/sbin/clamav-milter: --timeout must >> not be given if --external is not given > Add --timeout=0 to /etc/sysconfig/clamav-milter and it will > work. It's not really a package problem, but it can be fixed by the > package. :-) I tried 1 to 20 and no options, but it would not start ... I put the packages back in place ... I think this is a package problem, if something has changed, as I have run into this problem that we lost mail after this update. I'm sure I have read that and upgrade should not break a system ... Anyway, the right fix quickly sorts this problem out. Thanks Mailed Lee From andreas at bawue.net Fri Jul 29 13:57:35 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 29 Jul 2005 15:57:35 +0200 (CEST) Subject: New package, review needed: icecast In-Reply-To: <1122644188.9931.10.camel@thomas.amantes> References: <1122644188.9931.10.camel@thomas.amantes> Message-ID: On Fri, 29 Jul 2005, Thomas Vander Stichele wrote: > If you're going to package a branch, you should make a separate package > completely. If upstream doesn't feel it should be released as the main > branch, there is a reason. Uhm, well. Karl is one of the upstream coders and his branch is located on svn.xiph.org, so it's not exactly some random hack's branch. As far as I can see, his branch is just used to test new code which will then make it into the main branch. Thus the codebase is _very_ similar to icecast-trunk. > You could do this by using transform-name for configure, or by making a > package with a different name that conflicts with a package named > "icecast". transform-name? Never heard of that. What would you suggest? Naming the package icecast-kh? And conflicting it with icecast while providing a virtual icecast package at the same time? bye, andreas From alex at dalloz.de Fri Jul 29 14:34:52 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Fri, 29 Jul 2005 16:34:52 +0200 Subject: New clamav-milter problem ... In-Reply-To: <42EA33D5.10403@leenx.co.za> References: <20050729132005.DB67E73898@hormel.redhat.com> <42EA33D5.10403@leenx.co.za> Message-ID: <1122647692.21238.18.camel@serendipity.dogma.lan> Am Fr, den 29.07.2005 schrieb C.Lee Taylor um 15:49: > >> Starting clamav-milter: /usr/sbin/clamav-milter: --timeout must > >> not be given if --external is not given > > > Add --timeout=0 to /etc/sysconfig/clamav-milter and it will > > work. It's not really a package problem, but it can be fixed by the > > package. :-) > > I tried 1 to 20 and no options, but it would not start ... I put the > packages back in place ... > > I think this is a package problem, if something has changed, as I have > run into this problem that we lost mail after this update. I'm sure I > have read that and upgrade should not break a system ... I don't share the opinion that this change could have or should have been covered by any mechanism inside the clamav-milter package. The configuration files are set properly in spec with "%config(noreplace)". For system critical updates I feel the user has to read about possible changes before applying the update. How should the package know, how you individually configured your clamav-milter to act? The fault is more an upstream problem, as the Release Notes (horribly formatted this time) do not mention the change in the milter behaviour. But there was short discussion about "--external" and "--timeout" on the clamav mailing list. No, you normally lost no mail ("lost" in the meaning the mail disappear to electronic nirvana == discarding). If there is a milter problem - like a milter misconfiguration so it fails to start - there are 3 ways the case is handled, depending how _you_ configured the milter to act: 1) F= -> accept mail anyway and proceed it 2) F=T -> answer the sending MTA with a temporary failure notice (DSN 4xx) 3) F=R -> reject the connection of foreign MTA with a DSN 5xx I recommend using "F=T" for the clamav-milter (made good experiences with that setting), the %description text in the clamav-milter rpm speaks about "F=". "F=R" should be avoided as it depends on the sender side whether it tries to send the mail message again or not. In any case (at least if the sender MTA is RFC conform) the sender gets a mail sending failure notice, so he knows that the mail did not reach the recipient. > Anyway, the right fix quickly sorts this problem out. > > Thanks > Mailed > Lee Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From thomas at apestaart.org Fri Jul 29 15:00:55 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 29 Jul 2005 17:00:55 +0200 Subject: New package, review needed: icecast In-Reply-To: References: <1122644188.9931.10.camel@thomas.amantes> Message-ID: <1122649255.9931.15.camel@thomas.amantes> Hi, On Fri, 2005-07-29 at 15:57 +0200, Andreas Thienemann wrote: > On Fri, 29 Jul 2005, Thomas Vander Stichele wrote: > > > If you're going to package a branch, you should make a separate package > > completely. If upstream doesn't feel it should be released as the main > > branch, there is a reason. > Uhm, well. Karl is one of the upstream coders and his branch is located on > svn.xiph.org, so it's not exactly some random hack's branch. I didn't say that :) I know who Karl is. But there's a reason his branch isn't mainline - it's precisely because he is moving fast on features a lot that his branch is not the mainline. It's a deliberate choice, and hence it doesn't make sense to package the branch and have people believe it's the official stable icecast. > As far as I can see, his branch is just used to test new code which will > then make it into the main branch. > Thus the codebase is _very_ similar to icecast-trunk. It's not - it's a bit more unstable, and it's precisely so because he's moving fast on features. > > You could do this by using transform-name for configure, or by making a > > package with a different name that conflicts with a package named > > "icecast". > transform-name? Never heard of that. from configure --help: Program names: --program-prefix=PREFIX prepend PREFIX to installed program names --program-suffix=SUFFIX append SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names This allows you to install stuff with a slightly different name. > What would you suggest? Naming the package icecast-kh? And conflicting it > with icecast while providing a virtual icecast package at the same time? If you use program transform name, they can be installed side by side with a little work, and that would probably be the nicest to do. If you can't be bothered, then a conflicts makes the most sense, but I wouldn't have it provide an actual icecast package. People would be duped into thinking they get the actual icecast release, and might be turned off if it crashes for whatever reason. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> "Don't worry, Joey, it's unisex." "Maybe you need sex, I just had some a couple of days ago !" "No, no, U-N-I-sex !" "Well, I ain't gonna say no to that !" <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From andreas at bawue.net Fri Jul 29 15:13:50 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 29 Jul 2005 17:13:50 +0200 (CEST) Subject: New package, review needed: icecast In-Reply-To: <1122649255.9931.15.camel@thomas.amantes> References: <1122644188.9931.10.camel@thomas.amantes> <1122649255.9931.15.camel@thomas.amantes> Message-ID: On Fri, 29 Jul 2005, Thomas Vander Stichele wrote: > I didn't say that :) I know who Karl is. I just wanted to make sure. ;) > But there's a reason hisB branch isn't mainline - it's precisely because > he is moving fast on features a lot that his branch is not the mainline. > It's a deliberate choice, and hence it doesn't make sense to package the > branch and have people believe it's the official stable icecast. Hmm. I thought that would have been made clear by the version number. But hey, I can just whip up a stable icecast release as well. > > Thus the codebase is _very_ similar to icecast-trunk. > It's not - it's a bit more unstable, and it's precisely so because he's > moving fast on features. The features I'v been interested in in the past have all been folded into trunk. That's what I was referring to with kh being similar to trunk. And yes, his features are a bit more experimental. But the last year I have been running several icecast-kh daemons in productive use and not one of them did crash, something which I can unfortunately not say about the ices tools . ;) > This allows you to install stuff with a slightly different name. Ohh. Neat! > If you use program transform name, they can be installed side by side > with a little work, and that would probably be the nicest to do. > If you can't be bothered, then a conflicts makes the most sense, Okay, I'll see what I can manage there. > but I wouldn't have it provide an actual icecast package. People would > be duped into thinking they get the actual icecast release, and might be > turned off if it crashes for whatever reason. Hmmm. WE should think about offering some virtual package such as webserver is being provided by httpd. That way we could have clients depend on streaming-server and it doesn't matter if the user is installing icecast, icecast-kh or shoutcast or whatever.... bye, andreas From katzj at redhat.com Fri Jul 29 15:38:23 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 29 Jul 2005 11:38:23 -0400 Subject: More status on the Extras buildsystem (fwd for those not on -maintainers) Message-ID: <1122610894.8768.17.camel@bree.local.net> We should now be up and running with all of the build machines for the Extras build system. There are now 3 machines for doing x86_64 and i386 builds and one machine for ppc builds. I've successfully done a build for FE3, FE4 and the development tree and so think everything should be sanely set up. If not, DO NOT SEND MAIL TO SETH :-) You can send mail here, to fedora-extras-list or file a bug in bugzilla against the Fedora Infrastructure product, buildsys component. Also, I've added a 'make plague' target to the Extras Makefile.common. This is for testing prior to switching 'make build' over to using plague-client. If you install the packages Seth pointed to[1], then this should work. If not, let me know[2]. And thirdly, there is going to be some network work going on tomorrow (Friday) evening between 2100 and 0200[3]. So some hiccups might occur then. Builds will hopefully resume after the outage is over, but worst case scenario is that I might have to kick stuff when I wake up Saturday morning. Jeremy [1] http://fedoraproject.org/wiki/Extras/BuildSystemClientSetup [2] A patch would be even better... :) [3] Timezone is America/New_York which should currently be -0400. You can use 'TZ="America/New_York" date' to find out the time here and figure out your offset from it. -- Fedora-maintainers mailing list Fedora-maintainers at redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers From mitr at volny.cz Fri Jul 29 17:31:05 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 29 Jul 2005 19:31:05 +0200 Subject: WINE In-Reply-To: <1122615559.4941.60.camel@mccallum.corsepiu.local> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> <1122615559.4941.60.camel@mccallum.corsepiu.local> Message-ID: <20050729173105.GC27703@chrys.ms.mff.cuni.cz> On Fri, Jul 29, 2005 at 07:39:19AM +0200, Ralf Corsepius wrote: > What you say here doesn't make much sense, because GL support in Linux > is implemented via shared libraries. > > I.e. you normally compile against Mesa-LibGL's headers/API and use an > arbitrary libGL.so.1 at run-time. I.e. the GL spead-up provided by > NVidia's GL is a run-time feature, not a built-time dependency. Last time I checked (which is more than a year ago), NVidia's GL provided some API not available in Mesa. Usage of such APIs results also in a run-time dependency. (I don't know whether this is relevant to the way Wine uses GL.) Mirek From Nicolas.Mailhot at laPoste.net Fri Jul 29 18:06:22 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 29 Jul 2005 20:06:22 +0200 Subject: WINE In-Reply-To: <20050729173105.GC27703@chrys.ms.mff.cuni.cz> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> <1122615559.4941.60.camel@mccallum.corsepiu.local> <20050729173105.GC27703@chrys.ms.mff.cuni.cz> Message-ID: <1122660382.23200.11.camel@rousalka.dyndns.org> Le vendredi 29 juillet 2005 ? 19:31 +0200, Miloslav Trmac a ?crit : > On Fri, Jul 29, 2005 at 07:39:19AM +0200, Ralf Corsepius wrote: > > What you say here doesn't make much sense, because GL support in Linux > > is implemented via shared libraries. > > > > I.e. you normally compile against Mesa-LibGL's headers/API and use an > > arbitrary libGL.so.1 at run-time. I.e. the GL spead-up provided by > > NVidia's GL is a run-time feature, not a built-time dependency. > Last time I checked (which is more than a year ago), NVidia's GL > provided some API not available in Mesa. Usage of such APIs > results also in a run-time dependency. > > (I don't know whether this is relevant to the way Wine uses GL.) I'm sure numerous people don't care at all about the GL part (people using notes under linux...). It's not nice to put wine in livna and make it depend on nvidia's closed stuff. If it's so important, why no put wine in FE and rebuild a special version (other package name) in livna ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Fri Jul 29 18:23:58 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 13:23:58 -0500 Subject: WINE In-Reply-To: <1122660382.23200.11.camel@rousalka.dyndns.org> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> <1122615559.4941.60.camel@mccallum.corsepiu.local> <20050729173105.GC27703@chrys.ms.mff.cuni.cz> <1122660382.23200.11.camel@rousalka.dyndns.org> Message-ID: <1122661438.2775.87.camel@localhost.localdomain> On Fri, 2005-07-29 at 20:06 +0200, Nicolas Mailhot wrote: > I'm sure numerous people don't care at all about the GL part (people > using notes under linux...). It's not nice to put wine in livna and make > it depend on nvidia's closed stuff. If it's so important, why no put > wine in FE and rebuild a special version (other package name) in > livna ? We could probably do that. Wine in FE. WineGL in Livna. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nphilipp at redhat.com Fri Jul 29 19:07:16 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 29 Jul 2005 21:07:16 +0200 Subject: WINE In-Reply-To: <1122661438.2775.87.camel@localhost.localdomain> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> <1122615559.4941.60.camel@mccallum.corsepiu.local> <20050729173105.GC27703@chrys.ms.mff.cuni.cz> <1122660382.23200.11.camel@rousalka.dyndns.org> <1122661438.2775.87.camel@localhost.localdomain> Message-ID: <1122664037.28527.49.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-07-29 at 13:23 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-07-29 at 20:06 +0200, Nicolas Mailhot wrote: > > > I'm sure numerous people don't care at all about the GL part (people > > using notes under linux...). It's not nice to put wine in livna and make > > it depend on nvidia's closed stuff. If it's so important, why no put > > wine in FE and rebuild a special version (other package name) in > > livna ? > > We could probably do that. > > Wine in FE. WineGL in Livna. I don't think we need to do this as all other projects using GL seem to manage with being compiled against normal Mesa libGL* and then run against nVidia's libGL*. From what I've seen the symbols used aren't in the applications' code but get automatically linked when compiling against nVidia's libGL*. There's simply no need to limit 3D to owners of nVidia cards if all the game producers get by without resorting to that. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From buildsys at fedoraproject.org Fri Jul 29 19:14:20 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jul 2005 15:14:20 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050729191420.D1F467FD0@extras64> Packages built and released for Fedora Extras 3: 7 QuantLib-0.3.10-1.fc3 bluefish-1.0.2-1.fc3 clamav-0.86.2-3.fc3 inkscape-0.42-2.fc3 pptp-1.7.0-1.fc3 scim-1.4.0-2.fc3 scmxx-0.8.0-1.fc3 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 Jul 29 19:18:38 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jul 2005 15:18:38 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050729191838.6A9E27FD0@extras64> Packages built and released for Fedora Extras 4: 15 abiword-2.2.9-2.fc4 bluefish-1.0.2-1.fc4 clamav-0.86.2-3.fc4 cln-1.1.9-4.fc4 contact-lookup-applet-0.13-1.fc4 freeciv-2.0.4-1.fc4 inkscape-0.42-2.fc4 libapreq2-2.06-1.fc4 nexuiz-1.1-1.fc4 nexuiz-data-1.1-1 nfswatch-4.99.4-1.fc4 pptp-1.7.0-1.fc4 scim-1.4.0-2.fc4 scim-anthy-0.5.3-1.fc4 scmxx-0.8.0-1.fc4 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 Jul 29 19:37:45 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jul 2005 15:37:45 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050729193745.A1C567FD0@extras64> Packages built and released for Fedora Extras development: 63 TeXmacs-1.0.5.6-2.fc5 aiksaurus-1.2.1-9 at-poke-0.2.2-2 bash-completion-20050721-1.fc5 bittorrent-4.1.3-1.fc5 bluefish-1.0.2-1.fc5 cd-discid-0.9-4 cksfv-1.3-4 clamav-0.86.2-2.fc5 contact-lookup-applet-0.13-2.fc5 dvb-apps-1.1.0-1.fc5 epiphany-extensions-1.7.3-1 fish-1.12.0-1.fc5 freeciv-2.0.3-2.fc5 freeze-2.5.0-4 galculator-1.2.5-1.fc5 gdome2-0.8.1-1.fc5 gif2png-2.5.1-1.fc5 gkrellm-aclock-0.3.3-1.fc5 gkrellm-freq-0.1.1-2.fc5 glunarclock-0.32.4-1.fc5 hping2-2.0.0-0.5.rc3 icmpdn-0.3-2 id3lib-3.8.3-12.fc5 inadyn-1.95-1 inkscape-0.42-2.fc5 ip-sentinel-0.12-5.fc5 istanbul-0.1.1-4 leafpad-0.8.3-1.fc5 lft-2.31-3 libdnet-1.10-2.fc5 libevent-1.1a-2.fc5 liboggz-0.9.2-1.fc5 libstatgrab-0.11.1-3.fc5 libxml++-2.10.0-1.fc5 liferea-0.9.4-2.fc5 lighttpd-1.3.15-1.fc5 meld-1.0.0-1.fc5 mhonarc-2.6.15-2.fc5 moodss-20.3-1.fc5 naim-0.11.7.3.1-2.fc5 nedit-5.5-4 nexuiz-data-1.1-1 nfswatch-4.99.4-1.fc5 notecase-1.0.0-1.fc5 pam_abl-0.2.2-2.fc5 perl-Crypt-Blowfish-2.09-2.fc5 perl-DBD-SQLite-1.09-1.fc5 perl-DBD-SQLite-1.09-2.fc5 perl-ExtUtils-XSBuilder-0.27-2.fc5 pptp-1.7.0-1.fc5 proj-4.4.9-1.fc5 pygsl-0.3.2-4.fc5 rpmlint-0.70-4.fc5 scmxx-0.8.0-1.fc5 showimg-0.9.4.1-4.fc5 sylpheed-2.0.0-0.4.beta6 tetex-lgrind-3.67-7 uim-0.4.7-1.fc5 ulogd-1.23-2.fc5 umfpack-4.4-2 util-vserver-0.30.208-1.fc5 wesnoth-0.9.4-1.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From kjcole at gri.gallaudet.edu Fri Jul 29 20:05:55 2005 From: kjcole at gri.gallaudet.edu (Kevin Cole) Date: Fri, 29 Jul 2005 16:05:55 -0400 Subject: Request for review/sponsor: boa-constructor Message-ID: <42EA8C23.9050807@gri.gallaudet.edu> Hi all, Summary: Boa Constructor is a cross platform Python IDE and wxPython GUI Builder http://pchb1f.gallaudet.edu/~kjcole/Fedora/Extras/boa-constructor.spec http://pchb1f.gallaudet.edu/~kjcole/Fedora/Extras/boa-constructor-0.4.4-1.src.rpm http://pchb1f.gallaudet.edu/~kjcole/Fedora/Extras/boa-constructor-0.4.4-1.noarch.rpm As this is my first go at contributing anything, I'm sure I've missed something in spite of trying to read/follow all the guidelines. With any luck, however, not TOO much is missing/wrong. When/if approved, someone's going to either need to do all the CVS magic for me or, point me to "CVS for Dummies". -- Kevin Cole | Key ID: 0xE6F332C7 Gallaudet University | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | V/TTY: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From triad at df.lth.se Fri Jul 29 20:14:38 2005 From: triad at df.lth.se (Linus Walleij) Date: Fri, 29 Jul 2005 22:14:38 +0200 (CEST) Subject: New package: libnjb Message-ID: Doing a second try for this one, sorry for a previous attempt some months ago when the account wasn't set up properly before this letter. Things are better now. Libnjb is a library for accessing digital audio players based on Creative Technology hardware. This includes the Creative Jukebox, Creative Jukebox 2, 3, Zen, Zen USB 2.0, NX, Xtra, Touch and Micro plus the OEM manufactured Dell Devices: Dell DJ, Dell DJ 2nd generation and Dell Pocket DJ. The library is built on top of libusb. libnjb is under the BSD license. We have had a maintainer for Debian for some time, and are now looking into including the library with the Fedora extras. I have been rolling Fedora / Red Hat packages on the project page for quite some time. It might need splitting in a separate "-devel" RPM for the .h file and perhaps the docs should be in that RPM too. A package reviewer and a sponsor for my user is humbly requested. Michael Schwendt knows me from the past SIDplay ages I believe. Project URL: http://libnjb.sourceforge.net/ SRPM URL: http://sourceforge.net/project/showfiles.php?group_id=32528 Yours, Linus Walleij From rc040203 at freenet.de Fri Jul 29 20:50:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 22:50:22 +0200 Subject: New package: libnjb In-Reply-To: References: Message-ID: <1122670223.4941.178.camel@mccallum.corsepiu.local> On Fri, 2005-07-29 at 22:14 +0200, Linus Walleij wrote: > A package reviewer and a sponsor for my user is humbly requested. > Project URL: http://libnjb.sourceforge.net/ > > SRPM URL: http://sourceforge.net/project/showfiles.php?group_id=32528 You should make this spec files more compliant to FE-conventions. Please read http://fedoraproject.org/wiki/PackagingGuidelines - "Prefix:", "Packager:" - Add missing devel package - Consider %configure --disable-shared - Superfluous "Requires:" libusb, zlib, ncurses - Non-standard docdir - IMO, there is no need for a separate doc package. I'd recommend to put them into the base or devel package's standard docdir. "rpm -i --excludedocs" will automatically exclude them for people not wanting them. + Package builds fine Ralf From nman64 at n-man.com Fri Jul 29 21:17:55 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 29 Jul 2005 16:17:55 -0500 Subject: WINE In-Reply-To: <1122664037.28527.49.camel@gibraltar.stuttgart.redhat.com> References: <1121454063.10327.26.camel@localhost> <1121462554.2755.118.camel@localhost.localdomain> <1121464322.10327.38.camel@localhost> <42D836C5.9060306@n-man.com> <1122596245.2775.9.camel@localhost.localdomain> <1122615559.4941.60.camel@mccallum.corsepiu.local> <20050729173105.GC27703@chrys.ms.mff.cuni.cz> <1122660382.23200.11.camel@rousalka.dyndns.org> <1122661438.2775.87.camel@localhost.localdomain> <1122664037.28527.49.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42EA9D03.9040605@n-man.com> Nils Philippsen wrote: >On Fri, 2005-07-29 at 13:23 -0500, Tom 'spot' Callaway wrote: > > >>On Fri, 2005-07-29 at 20:06 +0200, Nicolas Mailhot wrote: >> >> >> >>>I'm sure numerous people don't care at all about the GL part (people >>>using notes under linux...). It's not nice to put wine in livna and make >>>it depend on nvidia's closed stuff. If it's so important, why no put >>>wine in FE and rebuild a special version (other package name) in >>>livna ? >>> >>> >>We could probably do that. >> >>Wine in FE. WineGL in Livna. >> >> > >I don't think we need to do this as all other projects using GL seem to >manage with being compiled against normal Mesa libGL* and then run >against nVidia's libGL*. From what I've seen the symbols used aren't in >the applications' code but get automatically linked when compiling >against nVidia's libGL*. There's simply no need to limit 3D to owners of >nVidia cards if all the game producers get by without resorting to that. > >Nils > > As someone who has nVidia cards and has used Wine RPMs not compiled against the nVidia stuff, I can say that Wine works just fine with or without nVidia's GL stuff on nVidia and non-nVidia systems. There is absolutely no reason to build Wine packages with requirements for nVidia. If there are no legal issues, there is absolutely no reason that Wine can't be included in Extras and only in Extras. Users with nVidia hardware could use the Wine packages from Extras without any problems. I would, however, strongly advise that if the WineTools software is also to be packaged, that it be placed in Livna. WineTools is a separate project, but very useful to Wine users in getting a larger variety of Windows programs working. While WineTools does not directly include any proprietary technology that I'm aware of, its sole purpose is downloading and installing proprietary packages, most of which are made by Microsoft, in order resolve many dependency concerns for Windows software. This is definitely not something that belongs in Core or Extras. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From alexl at users.sourceforge.net Fri Jul 29 21:31:30 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 29 Jul 2005 14:31:30 -0700 Subject: Request for review/sponsor: boa-constructor In-Reply-To: <42EA8C23.9050807@gri.gallaudet.edu> (Kevin Cole's message of "Fri, 29 Jul 2005 16:05:55 -0400") References: <42EA8C23.9050807@gri.gallaudet.edu> Message-ID: >>>>> "KC" == Kevin Cole writes: KC> Hi all, Summary: Boa Constructor is a cross platform Python IDE KC> and wxPython GUI Builder KC> http://pchb1f.gallaudet.edu/~kjcole/Fedora/Extras/boa-constructor.spec Not a full review, but I just noticed this: Requires: wxPython %{_bindir}/python%{pyver} The name of the wxPython package in Extras is wxPythonGTK2, so this should be: Requires: wxPythonGTK2 %{_bindir}/python%{pyver} Alex From nwolovick at gmail.com Fri Jul 29 23:45:55 2005 From: nwolovick at gmail.com (=?ISO-8859-1?Q?Nicol=E1s_Wolovick?=) Date: Fri, 29 Jul 2005 20:45:55 -0300 Subject: Request for review: gnome-applet-bubblemon Message-ID: >--------- Mensaje reenviado ---------- >From: Ignacio Vazquez-Abrams >To: Discussion related to Fedora Extras >Date: Thu, 28 Jul 2005 08:42:17 -0400 >Subject: Re: Request for review: gnome-applet-bubblemon >On Thu, 2005-07-28 at 07:24 -0300, Nicol?s Wolovick wrote: >> SPEC:http://www.cs.famaf.unc.edu.ar/~nicolasw/Otros/gnome-applet-bubblemon.spec > >- Remove the hardcoded disttags >- Remove the explicit Requires >- --prefix and --mandir are redundant with %configure >- Variables should come after make in the command line, not before >- Use install, not install-strip in %install >- Should not own %{_datadir}/gnome-2.0 >- Use %find_lang instead of owning %{_datadir}/locale Thanks for the tips. I've updated the package and here you can find it. SPEC:http://www.cs.famaf.unc.edu.ar/~nicolasw/Otros/gnome-applet-bubblemon.spec SRPM:http://www.cs.famaf.unc.edu.ar/~nicolasw/Otros/gnome-applet-bubblemon-2.0.4-3.src.rpm Please tellme how to follow the process if everything is ok. Regards, Nicolas From Mail-Lists at karan.org Sat Jul 30 00:28:21 2005 From: Mail-Lists at karan.org (Karanbir Singh) Date: Sat, 30 Jul 2005 01:28:21 +0100 Subject: Request for review: netselect In-Reply-To: <20050529144436.GA25071@lisas.de> References: <20050513160118.GA17721@lisas.de> <1116006752.4707.15.camel@rydia.hardsun.net> <20050516091151.GA22153@lisas.de> <1116328779.22682.48.camel@rydia.hardsun.net> <20050529144436.GA25071@lisas.de> Message-ID: <42EAC9A5.6050601@karan.org> Adrian Reber wrote: > On Tue, May 17, 2005 at 04:19:39AM -0700, Aaron Kurtz wrote: > >>>>- Considering this is Fedora Extras, an entirely separate -yum package >>>>is a bit unnecessary. Just roll it in. >>> >>>I would rather like to leave it as two packages. >> >>Why? It's just one file in the -yum package. > > > Okay, I have added it back to the netselect package. > > >>>>= DistTags. http://fedoraproject.org/wiki/DistTag >>> >>>Ahh... not yet. If it becomes necessary. >> >>Never a bad time to start good habits. I wonder why it's not mandatory. > > > dist tag has been added. > > http://lisas.de/~adrian/rpm/netselect-0.3-1.src.rpm > > Adrian > What just wondering what became of this package ? -- Karanbir Singh : http://www.karan.org/ GnuPG Public Key : http://www.karan.org/publickey.asc From joelwreed at comcast.net Sat Jul 30 01:33:35 2005 From: joelwreed at comcast.net (joel reed) Date: Fri, 29 Jul 2005 21:33:35 -0400 Subject: Request for review (round3): libxslt-plugin-regexp and libxslt-plugin-dates-and-time Message-ID: <20050730013335.GA31155@comcast.net> I posted a request for review on July 8th and July 16th, and received helpful feedback from Ignacio Vazquez-Abrams and Rui Miguel Seabra. I believe I've addressed their concerns. The updated spec/rpm files can be found here: http://home.comcast.net/~joelwreed/libxslt-plugin-regexp-0.5-1.src.rpm http://home.comcast.net/~joelwreed/libxslt-plugin-regexp.spec http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times-0.2-1.src.rpm http://home.comcast.net/~joelwreed/libxslt-plugin-dates-and-times.spec Do the spec files look good now? As a reminder, the following two libxslt plugins add support for a few http://exslt.org extension functions. 1. regular-expressions Implements regexp:test, regexp.match, and regexp:replace using PCRE. 2. dates-and-times Implements format:date using libgcj. jr From tcallawa at redhat.com Sat Jul 30 02:02:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 21:02:37 -0500 Subject: Review: perl-Lingua-EN-Inflect In-Reply-To: <42EADD19.1070709@di.uminho.pt> References: <1120768388.9303.40.camel@localhost.localdomain> <42EADD19.1070709@di.uminho.pt> Message-ID: <1122688957.2775.105.camel@localhost.localdomain> On Sat, 2005-07-30 at 02:51 +0100, Jos? Pedro Oliveira wrote: > Tom 'spot' Callaway wrote: > > ... > > perl-Lingua-EN-Inflect: > > Convert singular to plural, select "a" or "an" > > ... > > Needswork: > * unowned directory problem: the module should also own the > Lingua directory > * file permission problems: executable doc files and perl module > > > The following patch corrects the above problems: Patch committed, -3 resolves these issues. SRPM: http://auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect-1.89-3.src.rpm SPEC: http://auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect.spec Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jpo at di.uminho.pt Sat Jul 30 02:07:14 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 30 Jul 2005 03:07:14 +0100 Subject: Review: perl-Lingua-EN-Inflect-Number In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <42EAE0D2.5090306@di.uminho.pt> Tom 'spot' Callaway wrote: > perl-Lingua-EN-Inflect-Number: > Force number of words to singular or plural Needwork: * can verify license no file inside the tarball mentions it (license/copyright) Distributable for the time being? * superfluous requirement: perl(Lingua::EN::Inflect) jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Sat Jul 30 01:51:21 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 30 Jul 2005 02:51:21 +0100 Subject: Review: perl-Lingua-EN-Inflect In-Reply-To: <1120768388.9303.40.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> Message-ID: <42EADD19.1070709@di.uminho.pt> Tom 'spot' Callaway wrote: > ... > perl-Lingua-EN-Inflect: > Convert singular to plural, select "a" or "an" > ... Needswork: * unowned directory problem: the module should also own the Lingua directory * file permission problems: executable doc files and perl module The following patch corrects the above problems: --- perl-Lingua-EN-Inflect.spec.spot.2 2005-07-08 21:02:34.000000000 +0100 +++ perl-Lingua-EN-Inflect.spec 2005-07-12 04:43:47.000000000 +0100 @@ -17,6 +17,7 @@ %prep %setup -q -n Lingua-EN-Inflect-%{version} +chmod -x Changes README lib/Lingua/EN/Inflect.pm %build %{__perl} Makefile.PL INSTALLDIRS=vendor @@ -38,7 +39,7 @@ %files %defattr(-,root,root,-) %doc Changes README -%{perl_vendorlib}/Lingua/EN +%{perl_vendorlib}/Lingua/ %{_mandir}/man3/*.3* jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Sat Jul 30 02:20:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 21:20:28 -0500 Subject: Review: perl-Lingua-EN-Inflect-Number In-Reply-To: <42EAE0D2.5090306@di.uminho.pt> References: <1120768388.9303.40.camel@localhost.localdomain> <42EAE0D2.5090306@di.uminho.pt> Message-ID: <1122690028.2775.110.camel@localhost.localdomain> On Sat, 2005-07-30 at 03:07 +0100, Jos? Pedro Oliveira wrote: > Tom 'spot' Callaway wrote: > > perl-Lingua-EN-Inflect-Number: > > Force number of words to singular or plural > > Needwork: > * can verify license > no file inside the tarball mentions it (license/copyright) > > Distributable for the time being? > > * superfluous requirement: perl(Lingua::EN::Inflect) Fixed in -3: SRPM: http://www.auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect-Number-1.1-3.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect-Number.spec Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jpo at di.uminho.pt Sat Jul 30 02:38:40 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Sat, 30 Jul 2005 03:38:40 +0100 Subject: Review: perl-Lingua-EN-Inflect In-Reply-To: <1122688957.2775.105.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <42EADD19.1070709@di.uminho.pt> <1122688957.2775.105.camel@localhost.localdomain> Message-ID: <42EAE830.7060507@di.uminho.pt> Tom 'spot' Callaway wrote: > ... > Patch committed, -3 resolves these issues. > > SRPM: > http://auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect-1.89-3.src.rpm > SPEC: > http://auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect.spec Approved. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Sat Jul 30 02:39:20 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Sat, 30 Jul 2005 03:39:20 +0100 Subject: Review: perl-Lingua-EN-Inflect-Number In-Reply-To: <1122690028.2775.110.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <42EAE0D2.5090306@di.uminho.pt> <1122690028.2775.110.camel@localhost.localdomain> Message-ID: <42EAE858.7030506@di.uminho.pt> Tom 'spot' Callaway wrote: > ... > Fixed in -3: > > SRPM: > http://www.auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect-Number-1.1-3.src.rpm > SPEC: > http://www.auroralinux.org/people/spot/review/Maypole/perl-Lingua-EN-Inflect-Number.spec > Approved. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ed at eh3.com Sat Jul 30 02:52:00 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 29 Jul 2005 22:52:00 -0400 Subject: Request for review: glpk In-Reply-To: <42E94316.1060800@ieee.org> References: <42E63D65.8040508@ieee.org> <604aa791050728131017a7a0d9@mail.gmail.com> <42E94316.1060800@ieee.org> Message-ID: <1122691920.7055.146.camel@ernie> On Thu, 2005-07-28 at 15:41 -0500, Quentin Spencer wrote: > That's odd. I just tried downloading it and it worked. Anyway, another > octave user has hosted some of my RPMs before, so I put this on his FTP > server: > ftp://coffee.phys.unm.edu/pub/dima/incoming/glpk-4.8-1.src.rpm Hi Quentin, Heres the promised glpk review: needswork: - a devel package should not install binaries -- please put the binaries into a separate non-devel package - the package installs 19 headers in /usr/include and they should probably be put in a subdirectory such as /usr/include/glpk - please add an "rm -rf ${RPM_BUILD_ROOT}" immediately after the "%install" line good: - name OK - source matches upstream - license OK - spec looks good - builds and installs for FC3 - no errors from rpmlint - no shared libs and, despite Ralf's incessant emails, I wouldn't sweat this detail -- it will be nice to eventually have shared libs (as you point out in the spec-file) but in the mean time it is certainly not a blocker for inclusion of this package into FE (it'll probably require some cooperation with upstream?) - dir ownership OK - permissions OK - no *.la files - no segfaults from the binaries So its mostly good and the few needswork items are easy to fix. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From jpo at di.uminho.pt Sat Jul 30 03:05:04 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Sat, 30 Jul 2005 04:05:04 +0100 Subject: Review: perl-CGI-Simple In-Reply-To: <1122522395.2645.25.camel@localhost.localdomain> References: <1120768388.9303.40.camel@localhost.localdomain> <42D2BE75.5010207@di.uminho.pt> <1122522395.2645.25.camel@localhost.localdomain> Message-ID: <42EAEE60.5070401@di.uminho.pt> Tom 'spot' Callaway wrote: > ... > All of these items are fixed in -3: > > SRPM: > http://www.auroralinux.org/people/spot/review/Maypole/perl-CGI-Simple-0.077-3.src.rpm > SPEC: > http://www.auroralinux.org/people/spot/review/Maypole/perl-CGI-Simple.spec > > Please re-review or approve. Approved. Minor request: When importing this module to CVS could you simplify and move the permissions change to the %prep section? Example: ---------- --- perl-CGI-Simple.spec.3 2005-07-28 04:40:27.000000000 +0100 +++ perl-CGI-Simple.spec 2005-07-30 04:23:43.000000000 +0100 @@ -17,9 +17,9 @@ %prep %setup -q -n Cgi-Simple-%{version} +chmod -x Changes README cgi-simple_vs_cgi-pm.html Simple.pm Simple/*.pm %build -chmod -x Changes README cgi-simple_vs_cgi-pm.html %{__perl} Makefile.PL INSTALLDIRS=vendor make @@ -29,8 +29,6 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' chmod -R u+w $RPM_BUILD_ROOT/* -chmod -R 644 $RPM_BUILD_ROOT%{perl_vendorlib}/CGI/*.pm -chmod -R 644 $RPM_BUILD_ROOT%{perl_vendorlib}/CGI/Simple/*.pm %check make test ---------- jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Sat Jul 30 03:07:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 22:07:09 -0500 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa79105072809402c436ba2@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> Message-ID: <1122692829.2775.118.camel@localhost.localdomain> On Thu, 2005-07-28 at 12:40 -0400, Jeff Spaleta wrote: > On 7/27/05, Tom 'spot' Callaway wrote: > > Package it up, and I'll look it over. If we need to make packaging > > policy changes, I'll help. > > > first draft package that doesn't make any attempt yet to split off > individual library bindings into seperate subpackages available at: > http://jef.is--a-geek.com/downloads/ruby-gnome2-all/ > I've built this in mock against x86 fc4 > > Clearly I'm going to want to split out the binary subpackages based on > individual subdirectories of the full source tarball... tedious but > not difficult to do. > > I'm more concerned about how rpm is catching the provided so files. > There's no indication that the provides are libraries in ruby's site > directory as compared to system lbraries. Is this going to be a > problem? Well, I don't think so. pygtk2 does the exact same thing: [spot at swoop blacs]$ rpm -q pygtk2 --provides _gtk.so atk.so gobject.so pango.so pygtk2 = 2.6.0-2 The only possible issue I could see is if something --required one of the pygtk2 .so files explicitly... but nothing does. I think you're in the clear. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From shishz at hotpop.com Sat Jul 30 03:17:05 2005 From: shishz at hotpop.com (Zing) Date: Fri, 29 Jul 2005 23:17:05 -0400 Subject: New upstream: snownews 1.5.7, seeking review & other stuff Message-ID: Hello folks, I have some requests: 1. review of update of snownews to 1.5.7: http://home.nycap.rr.com/nagaland/rpms/snownews.spec http://home.nycap.rr.com/nagaland/rpms/snownews-1.5.7-1.FC4.src.rpm http://home.nycap.rr.com/nagaland/rpms/snownews-1.5.7-1.FC4.i386.rpm https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163627 2. your thoughts on a run-time charset patch: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155073 3. looking for a sponsor. thanks. From bugs.michael at gmx.net Sat Jul 30 07:04:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Jul 2005 09:04:15 +0200 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa79105072809402c436ba2@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> Message-ID: <20050730090415.4ffe13a6.bugs.michael@gmx.net> On Thu, 28 Jul 2005 12:40:04 -0400, Jeff Spaleta wrote: > I'm more concerned about how rpm is catching the provided so files. > There's no indication that the provides are libraries in ruby's site > directory as compared to system lbraries. Is this going to be a > problem? > > -jef > > rpm -q --provides -p ruby-gnome2-all/ruby-gnome2-all-0.12.0-1.i386.rpm > atk.so > gconf2.so > gdk_pixbuf2.so > glib2.so > gnome2.so > gnomecanvas2.so > gnomeprint2.so > gnomeprintui2.so > gnomevfs.so > gst.so > gtk2.so > gtk20.so > gtk22.so > gtkglext.so > gtkhtml2.so > gtksourceview.so > libart2.so > libgda.so > libglade2.so > panelapplet2.so > pango.so > rsvg2.so > ruby-gnome2-all = 0.12.0-1 This is a packaging bug, because it pollutes the list of SONAME provides in a dangerous way. None of these SONAMES are really installed by the package in a path, where installing the package would satisfy the dependency of a package which required one of these SONAMES. They are installed into a private path, not into a location where dynamic linker finds them. Hence they must not be "provided". I believe we've seen broken dependencies due to something like this before. One package I remember is OO.o in Core, which works around it by redefining the %__find_provides macro. From bugs.michael at gmx.net Sat Jul 30 08:22:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Jul 2005 10:22:26 +0200 Subject: Request for Review krecipes In-Reply-To: <200507262247.31982.dennis@ausil.us> References: <200507262247.31982.dennis@ausil.us> Message-ID: <20050730102226.76a4c31f.bugs.michael@gmx.net> On Tue, 26 Jul 2005 22:47:24 -0500, Dennis Gilmore wrote: > Hi All, > > Could someone please review krecipes for me. > SPEC: http://ausil.us/packages/krecipes.spec > SRPM: http://ausil.us/packages/krecipes-0.8.1-1.fc4.src.rpm * That it requires qt-MySQL (+mysql) qt-PostgreSQL (+postgresql) in addition to using SQLite is less than ideal, because the database support cannot be split off. PostgreSQL support is warned as being "beta". Dropping the explicit requirements doesn't do any harm. Krecipes warns in a graphical dialog about the Qt plugins not being found, so they are more of a "soft requirement" and could be dropped from the spec. * Clicking "Help" in the Wizard doesn't do anything. > Only things im not 100% sure about is > > rpmlint ../RPMS/i386/krecipes-0.8.1-1.fc4.i386.rpm > W: krecipes > symlink-should-be-relative /usr/share/doc/HTML/da/krecipes/common /usr/share/doc/HTML/da/common > rpmlint is right, since absolute symlinks can break more easily than relative symlinks. But it's not an issue, since the absolute paths are correct for Fedora Core. * Package summary reads like a marketing slogan, not like a good summary that explains what this package contains. Something more generic like "Application to manage recipes and shopping-lists" would be better. * Hint: Sourceforge URLs like http://download.sourceforge.net/... and http://dl.sf.net/... don't point to the web-based mirror selector, but directly to a mirror [ http://download.sourceforge.net/krecipes/krecipes-0.8.1.tar.gz ] [ http://dl.sf.net/krecipes/krecipes-0.8.1.tar.gz ] * In %build, the same QTLIB/QTINC fix as in "konversation" may be needed. * Empty %doc line should at least contain the licence file, probably also the TODO file. The rest looks okay, so feel free to fix in CVS. From buildsys at fedoraproject.org Sat Jul 30 09:29:05 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jul 2005 05:29:05 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050730092905.1617D7FD0@extras64> Packages built and released for Fedora Extras 3: 5 blacs-1.1-11.fc3 gambas-1.0.9-2.fc3 perl-DBD-SQLite-1.09-2.fc3 perl-Exporter-Lite-0.01-2.fc3 quilt-0.42-1.fc3 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 Sat Jul 30 09:30:25 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jul 2005 05:30:25 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050730093025.23B677FD0@extras64> Packages built and released for Fedora Extras 4: 7 QuantLib-0.3.10-1.fc4 gambas-1.0.9-2.fc4 perl-DBD-SQLite-1.09-2.fc4 perl-Exporter-Lite-0.01-2.fc4 perl-Gtk2-1.083-1.fc4 python-dateutil-1.0-1.fc4 scim-anthy-0.5.3-2.fc4 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 Sat Jul 30 09:34:11 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jul 2005 05:34:11 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050730093411.635337FD0@extras64> Packages built and released for Fedora Extras development: 4 QuantLib-0.3.10-1.fc5 freeciv-2.0.4-2.fc5 gambas-1.0.9-2.fc5 perl-Exporter-Lite-0.01-2.fc5 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From jspaleta at gmail.com Sat Jul 30 13:10:52 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 30 Jul 2005 09:10:52 -0400 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <20050730090415.4ffe13a6.bugs.michael@gmx.net> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> <20050730090415.4ffe13a6.bugs.michael@gmx.net> Message-ID: <604aa79105073006106c331057@mail.gmail.com> On 7/30/05, Michael Schwendt wrote: > This is a packaging bug, because it pollutes the list of SONAME provides > in a dangerous way. None of these SONAMES are really installed by the > package in a path, where installing the package would satisfy the > dependency of a package which required one of these SONAMES. They are > installed into a private path, not into a location where dynamic linker > finds them. Hence they must not be "provided". > > I believe we've seen broken dependencies due to something like this > before. One package I remember is OO.o in Core, which works around it by > redefining the %__find_provides macro. Yeah this is exactly my concern. I'm working on splitting out subpackages for each component now. What should I redefine %__find_provides too? Does it matter where I redefine it in the spec? -jef From kjcole at gri.gallaudet.edu Sat Jul 30 13:53:03 2005 From: kjcole at gri.gallaudet.edu (Kevin Cole) Date: Sat, 30 Jul 2005 09:53:03 -0400 Subject: Request for review/sponsor: boa-constructor In-Reply-To: References: <42EA8C23.9050807@gri.gallaudet.edu> Message-ID: <42EB863F.9070903@gri.gallaudet.edu> Alex Lancaster wrote: >>>>>>"KC" == Kevin Cole writes: > > KC> Hi all, Summary: Boa Constructor is a cross platform Python IDE > KC> and wxPython GUI Builder > > KC> http://pchb1f.gallaudet.edu/~kjcole/Fedora/Extras/boa-constructor.spec > > Not a full review, but I just noticed this: > > Requires: wxPython %{_bindir}/python%{pyver} > > The name of the wxPython package in Extras is wxPythonGTK2, so this > should be: > > Requires: wxPythonGTK2 %{_bindir}/python%{pyver} Thanks... but... ;-) I guess I've mixed and matched from non-Fedora sources more than I remembered. Should I then repackage the wxPython that I got from the Python web site, since it goes by a rather ungainly name and appears to be ahead of what's in Extras? Specifically should I try to make the names of the following more closely match Fedora's? What I've installed are: wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm wxPython-common-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm which I built from: wxPython2.6-2.6.1.0-1_py2.4.src.rpm And a naive question: Why didn't rpm complain when I installed my boa-constructor, since none of my packages is named wxPython? ("rpm -q wxPython" reports that no such beastie is installed.) -- Kevin Cole | Key ID: 0xE6F332C7 Gallaudet University | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | V/TTY: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 "Using vi is not a sin. It's a penance." -- St. IGNUcious, Church of Emacs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From paul at city-fan.org Sat Jul 30 18:12:31 2005 From: paul at city-fan.org (Paul Howarth) Date: Sat, 30 Jul 2005 19:12:31 +0100 Subject: Request for review/sponsor: boa-constructor In-Reply-To: <42EB863F.9070903@gri.gallaudet.edu> References: <42EA8C23.9050807@gri.gallaudet.edu> <42EB863F.9070903@gri.gallaudet.edu> Message-ID: <1122747151.2851.130.camel@laurel.intra.city-fan.org> On Sat, 2005-07-30 at 09:53 -0400, Kevin Cole wrote: > Alex Lancaster wrote: > >>>>>>"KC" == Kevin Cole writes: > > > > KC> Hi all, Summary: Boa Constructor is a cross platform Python IDE > > KC> and wxPython GUI Builder > > > > KC> http://pchb1f.gallaudet.edu/~kjcole/Fedora/Extras/boa-constructor.spec > > > > Not a full review, but I just noticed this: > > > > Requires: wxPython %{_bindir}/python%{pyver} > > > > The name of the wxPython package in Extras is wxPythonGTK2, so this > > should be: > > > > Requires: wxPythonGTK2 %{_bindir}/python%{pyver} > > Thanks... but... ;-) I guess I've mixed and matched from non-Fedora > sources more than I remembered. Should I then repackage the wxPython > that I got from the Python web site, since it goes by a rather ungainly > name and appears to be ahead of what's in Extras? Specifically should > I try to make the names of the following more closely match Fedora's? > What I've installed are: > > wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm > wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm > wxPython-common-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm > > which I built from: > > wxPython2.6-2.6.1.0-1_py2.4.src.rpm > > And a naive question: Why didn't rpm complain when I installed my > boa-constructor, since none of my packages is named wxPython? > ("rpm -q wxPython" reports that no such beastie is installed.) Try: $ rpm -q --whatprovides wxPython It is probably "provide"d by wxPythonGTK2. And the "Requires" is correct to be "wxPython" rather than "wxPythonGTK2", as a non-GTK2 implementation of wxPython should also be OK. Paul. -- Paul Howarth From buildsys at fedoraproject.org Sat Jul 30 19:47:37 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jul 2005 15:47:37 -0400 (EDT) Subject: Fedora Extras development Package Build Report Message-ID: <20050730194737.97A0C7FD0@extras64> Packages built and released for Fedora Extras development: 8 bluefish-1.0.2-2.fc5 fontforge-0.0-2.20050729.fc5 glunarclock-0.32.4-2.fc5 hdf-4.2r1-3.fc5 moomps-5.2-2.fc5 perl-SQL-Abstract-1.19-2.fc5 python-matplotlib-0.83.1-2.fc5 quilt-0.42-1.fc5 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 Sat Jul 30 19:47:45 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jul 2005 15:47:45 -0400 (EDT) Subject: Fedora Extras 3 Package Build Report Message-ID: <20050730194745.28ACD7FD0@extras64> Packages built and released for Fedora Extras 3: 5 bluefish-1.0.2-2.fc3 glunarclock-0.32.4-2.fc3 moomps-5.2-2.fc3 perl-SQL-Abstract-1.19-2.fc3 perl-Test-MockModule-0.05-3.fc3 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 Sat Jul 30 19:47:42 2005 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jul 2005 15:47:42 -0400 (EDT) Subject: Fedora Extras 4 Package Build Report Message-ID: <20050730194742.6674E7FD1@extras64> Packages built and released for Fedora Extras 4: 8 bluefish-1.0.2-2.fc4 fontforge-0.0-2.20050729.fc4 glunarclock-0.32.4-2.fc4 moomps-5.2-2.fc4 perl-SQL-Abstract-1.19-2.fc4 python-matplotlib-0.83.1-2.fc4 quilt-0.42-1.fc4 scim-1.4.0-2.1.fc4 For more information about the built packages please see the repository or the fedora Info Feed: http://fedoraproject.org/infofeed/ From alexl at users.sourceforge.net Sat Jul 30 21:03:19 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 30 Jul 2005 14:03:19 -0700 Subject: Request for review/sponsor: boa-constructor In-Reply-To: <42EB863F.9070903@gri.gallaudet.edu> (Kevin Cole's message of "Sat, 30 Jul 2005 09:53:03 -0400") References: <42EA8C23.9050807@gri.gallaudet.edu> <42EB863F.9070903@gri.gallaudet.edu> Message-ID: >>>>> "KC" == Kevin Cole writes: [...] KC> Thanks... but... ;-) I guess I've mixed and matched from KC> non-Fedora sources more than I remembered. Should I then repackage KC> the wxPython that I got from the Python web site, since it goes by KC> a rather ungainly name and appears to be ahead of what's in KC> Extras? Specifically should I try to make the names of the KC> following more closely match Fedora's? What I've installed are: Packages in Extras can only depend: Extras + Core + Updates. Mixing and matching non-Fedora sources for dependent packages is not supported. If boa-constructor needs wxPython 2.6 then you need to co-ordinate with the current wxPython maintainer to get them to update their package to 2.6, otherwise just build against the current version in Extras which is wxPythonGTK2-2.4.2.4-7. You cannot use/depend/build against a version of wxPython that is not in currently in Extras. KC> wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm KC> wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm KC> wxPython-common-gtk2-unicode-2.6.1.0-1_py2.4.i386.rpm KC> And a naive question: Why didn't rpm complain when I installed my KC> boa-constructor, since none of my packages is named wxPython? KC> ("rpm -q wxPython" reports that no such beastie is installed.) As explained by Paul, it appears that wxPythonGTK2 "Provides:" wxPython, so your "Requires:" statement should be sufficient, however it might be safer to be more explicit if boa-constructor needs a GTK2 version (and wouldn't otherwise work with a GTK1 version) to use the explicit wxPythonGTK2 in "Requires:". Not sure what the best thing to do is in this circumstance. Alex From alexl at users.sourceforge.net Sat Jul 30 21:25:10 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 30 Jul 2005 14:25:10 -0700 Subject: Request for review/sponsor: boa-constructor In-Reply-To: (Alex Lancaster's message of "Sat, 30 Jul 2005 14:03:19 -0700") References: <42EA8C23.9050807@gri.gallaudet.edu> <42EB863F.9070903@gri.gallaudet.edu> Message-ID: >>>>> "AL" == Alex Lancaster writes: [...] AL> If boa-constructor needs wxPython 2.6 then you need to co-ordinate AL> with the current wxPython maintainer to get them to update their AL> package to 2.6, otherwise just build against the current version AL> in Extras which is wxPythonGTK2-2.4.2.4-7. [...] In fact there is an outstanding Bugzilla request to update the wxPython package from 2.4 to 2.6: http://bugzilla.redhat.com/163440 It is waiting on an update to wxGTK2 from 2.4 to 2.6 (see http://bugzilla.redhat.com/154618). Panu Matilainen is the current wxPython maintainer, see: http://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras for the full list of maintainers. Alex From steve at silug.org Sat Jul 30 22:30:14 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 30 Jul 2005 17:30:14 -0500 Subject: Request for review: openvpn Message-ID: <20050730223014.GA2865@osiris.silug.org> I imported this into CVS a month or so ago based on some positive reviews, but I never received final approval... http://cvs.fedora.redhat.com/viewcvs/rpms/openvpn/devel/?root=extras 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 steve at silug.org Sat Jul 30 22:34:20 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 30 Jul 2005 17:34:20 -0500 Subject: Request for review: perl-Mail-SPF-Query and perl-Net-CIDR-Lite Message-ID: <20050730223420.GA2929@osiris.silug.org> Discussion on this died out... http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.1997-3.src.rpm And one dependency: http://ftp.kspei.com/pub/steve/rpms/perl-Net-CIDR-Lite-0.18-1.src.rpm The individual files are broken out here: http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query/ http://ftp.kspei.com/pub/steve/rpms/perl-Net-CIDR-Lite/ 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 steve at silug.org Sat Jul 30 22:35:40 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 30 Jul 2005 17:35:40 -0500 Subject: Request for review: perl-eperl Message-ID: <20050730223540.GA2983@osiris.silug.org> I posted this a while back, but I'm starting to think I'm the only person who is interested in it... ;-) http://ftp.kspei.com/pub/steve/rpms/perl-eperl-2.2.14-1.src.rpm http://ftp.kspei.com/pub/steve/rpms/perl-eperl/ 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 triad at df.lth.se Sat Jul 30 22:37:08 2005 From: triad at df.lth.se (Linus Walleij) Date: Sun, 31 Jul 2005 00:37:08 +0200 (CEST) Subject: New package: libnjb In-Reply-To: <1122670223.4941.178.camel@mccallum.corsepiu.local> References: <1122670223.4941.178.camel@mccallum.corsepiu.local> Message-ID: On Fri, 29 Jul 2005, Ralf Corsepius wrote: > You should make this spec files more compliant to FE-conventions. OK I've done my best for this upcoming libnjb-2.2.1 package: http://www.df.lth.se/~triad/fedora/libnjb-2.2.1-1.src.rpm > - Consider %configure --disable-shared Do you mean --disable-static? Because that's the only thing I saw in the guidelines. If not, please elaborate... > - Superfluous "Requires:" libusb, zlib, ncurses Removed. Out of curiosity: how does RPM resolve these dependencies? By looking at the linked .so files? I never quite understood that... > - Non-standard docdir Fixed. All is in /usr/share/doc/libnjb-VERSION/* now. > - IMO, there is no need for a separate doc package. I'd recommend to put > them into the base or devel package's standard docdir. > "rpm -i --excludedocs" will automatically exclude them for people not > wanting them. OK fixed. Linus From steve at silug.org Sat Jul 30 22:43:22 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 30 Jul 2005 17:43:22 -0500 Subject: Request for review: perl-BerkeleyDB Message-ID: <20050730224322.GA3124@osiris.silug.org> This is a requirement for amavisd-new: http://ftp.kspei.com/pub/steve/rpms/perl-BerkeleyDB-0.26-1.src.rpm http://ftp.kspei.com/pub/steve/rpms/perl-BerkeleyDB/ 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 steve at silug.org Sat Jul 30 22:48:19 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 30 Jul 2005 17:48:19 -0500 Subject: Request for review: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050730223420.GA2929@osiris.silug.org> References: <20050730223420.GA2929@osiris.silug.org> Message-ID: <20050730224819.GA3157@osiris.silug.org> On Sat, Jul 30, 2005 at 05:34:20PM -0500, Steven Pritchard wrote: > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.1997-3.src.rpm Sorry, typo: http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.997-3.src.rpm 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 alex at dalloz.de Sat Jul 30 22:58:22 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Sun, 31 Jul 2005 00:58:22 +0200 Subject: Request for review: openvpn In-Reply-To: <20050730223014.GA2865@osiris.silug.org> References: <20050730223014.GA2865@osiris.silug.org> Message-ID: <1122764302.21238.149.camel@serendipity.dogma.lan> Am So, den 31.07.2005 schrieb Steven Pritchard um 0:30: > I imported this into CVS a month or so ago based on some positive > reviews, but I never received final approval... > > http://cvs.fedora.redhat.com/viewcvs/rpms/openvpn/devel/?root=extras > > Steve O, that's the reason. I first missed OpenVPN in Extras and started to create an RPM my own, until I found your contribution being in CVS without any build request. Create %{_localstatedir}/run/openvpn/ with the RPM and not by init script run. I have some wishes: 1) Don't make --enable-pthread active for stable FC3 / FC4 builds, only development, due to it's experimental state. 2) Let us make some compile options selectable, like --enable-password-save or --disable-lzo. 3) Check for init script to be made more Fedora style. Using /etc/sysconfig/openvpn for default settings like user / group the tunnel runs under. Let a user kill or restart the tunnel running under his own uid/gid (useful for OpenVPN client tunnels). 4) Compilation agains lzo2 could be prepared for very soon to be released OpenVPN 2.0.1. lzo2 will be in Extras, I got approval. It offers encryption speed improvements on x86_64 arch. Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From steve at silug.org Sat Jul 30 23:26:55 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 30 Jul 2005 18:26:55 -0500 Subject: Request for review: openvpn In-Reply-To: <1122764302.21238.149.camel@serendipity.dogma.lan> References: <20050730223014.GA2865@osiris.silug.org> <1122764302.21238.149.camel@serendipity.dogma.lan> Message-ID: <20050730232655.GA3696@osiris.silug.org> On Sun, Jul 31, 2005 at 12:58:22AM +0200, Alexander Dalloz wrote: > Create %{_localstatedir}/run/openvpn/ with the RPM and not by init > script run. I'm surprised I missed that... > I have some wishes: > 1) Don't make --enable-pthread active for stable FC3 / FC4 builds, only > development, due to it's experimental state. I've had it enabled in my builds for months with no problems. > 2) Let us make some compile options selectable, like > --enable-password-save or --disable-lzo. Is it really worth it? > 3) Check for init script to be made more Fedora style. Using > /etc/sysconfig/openvpn for default settings like user / group the tunnel > runs under. Let a user kill or restart the tunnel running under his own > uid/gid (useful for OpenVPN client tunnels). The init script is eventually going to have to be dropped or completely rewritten. At some point I want openvpn to start like any other network interface. > 4) Compilation agains lzo2 could be prepared for very soon to be > released OpenVPN 2.0.1. lzo2 will be in Extras, I got approval. It > offers encryption speed improvements on x86_64 arch. That's another reason I really want the package as-is released. I'd like to switch devel over to 2.0.1_rc(whatever) and keep FC-3 and FC-4 on 2.0 for now. 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 alex at dalloz.de Sun Jul 31 00:57:53 2005 From: alex at dalloz.de (Alexander Dalloz) Date: Sun, 31 Jul 2005 02:57:53 +0200 Subject: Request for review: openvpn In-Reply-To: <20050730232655.GA3696@osiris.silug.org> References: <20050730223014.GA2865@osiris.silug.org> <1122764302.21238.149.camel@serendipity.dogma.lan> <20050730232655.GA3696@osiris.silug.org> Message-ID: <1122771473.21238.163.camel@serendipity.dogma.lan> Am So, den 31.07.2005 schrieb Steven Pritchard um 1:26: > On Sun, Jul 31, 2005 at 12:58:22AM +0200, Alexander Dalloz wrote: > > Create %{_localstatedir}/run/openvpn/ with the RPM and not by init > > script run. > > I'm surprised I missed that... I think thats why we review ;) > > I have some wishes: > > 1) Don't make --enable-pthread active for stable FC3 / FC4 builds, only > > development, due to it's experimental state. > > I've had it enabled in my builds for months with no problems. Good. Though I feel it shouldn't be used for stable branches. Can only speak from my humble opinion and can not quote something from the packaging guideline. configure says --enable-pthread Enable pthread support (Experimental for OpenVPN 2.0) this and that is what would count for me. > > 2) Let us make some compile options selectable, like > > --enable-password-save or --disable-lzo. > > Is it really worth it? Why not offer the choices? They don't cost much work in the spec file. For instance for the pthread case: # build with pthread support (Experimental for OpenVPN 2.0) %define with_pthread %{?_with_pthread:1}%{!?_with_pthread:0} and for %configure %{?_with_pthread:--enable-pthread} Would offer you a way to easily distinguish between development and stable branch build with different defaults for configure. > > 3) Check for init script to be made more Fedora style. Using > > /etc/sysconfig/openvpn for default settings like user / group the tunnel > > runs under. Let a user kill or restart the tunnel running under his own > > uid/gid (useful for OpenVPN client tunnels). > > The init script is eventually going to have to be dropped or > completely rewritten. At some point I want openvpn to start like any > other network interface. Sounds like a good plan. > > 4) Compilation agains lzo2 could be prepared for very soon to be > > released OpenVPN 2.0.1. lzo2 will be in Extras, I got approval. It > > offers encryption speed improvements on x86_64 arch. > > That's another reason I really want the package as-is released. I'd > like to switch devel over to 2.0.1_rc(whatever) and keep FC-3 and FC-4 > on 2.0 for now. As long as 2.0.1 isn't released but in RC state it shouldn't be in stable branches, I share that. OpenVPN 2.0 is the current stable for FC3 and FC4. > Steve Alexander -- 1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) Key fingerprint = CD40 0A91 7814 C1E4 5940 8E0E 1FD5 C316 866E D681 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Sun Jul 31 02:57:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 30 Jul 2005 22:57:36 -0400 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa79105073006106c331057@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> <20050730090415.4ffe13a6.bugs.michael@gmx.net> <604aa79105073006106c331057@mail.gmail.com> Message-ID: <604aa791050730195720ce34c4@mail.gmail.com> On 7/30/05, Jeff Spaleta wrote: > I'm working on splitting out subpackages for each component now. Second draft of the src.rpm which now splits out each sub-component from the ruby-gnome2-all tarball as a seperate binary package. Just a few questions I have left: 1) not sure whether to include the previously discussed changed to %__find_provides or not. 2) I'm excluding .h files... should i make one big -devel package are make seperate -devel subpackages that each pretty much includes just .h file per -devel package. 3)the damn sample scripts that I'm including as the %docs uses /usr/local/bin/ruby and rpm is picking that up and adding a requirement for /usr/loca/bin/ruby. What to do here? a)drop the samples from the packages b)patch the samples to use /usr/bin/ruby c)somehow disable rpm's automatic requires checking to avoid picking up /usr/local/bin/ruby as a requirement. The new ruby-gnome-all srpm and mock generated binary subpackages can be found at http://jef.is-a-geek.com/downloads/ruby-gnome2-all/ ruby-atk-0.12.0-2.i386.rpm ruby-gconf-0.12.0-2.i386.rpm ruby-gdkpixbuf-0.12.0-2.i386.rpm ruby-glib-0.12.0-2.i386.rpm ruby-gnome-0.12.0-2.i386.rpm ruby-gnomecanvas-0.12.0-2.i386.rpm ruby-gnomeprint-0.12.0-2.i386.rpm ruby-gnomeprintui-0.12.0-2.i386.rpm ruby-gnomevfs-0.12.0-2.i386.rpm ruby-gstreamer-0.12.0-2.i386.rpm ruby-gtk-0.12.0-2.i386.rpm ruby-gtkglext-0.12.0-2.i386.rpm ruby-gtkhtml2-0.12.0-2.i386.rpm ruby-gtksourceview-0.12.0-2.i386.rpm ruby-libart-0.12.0-2.i386.rpm ruby-libgda-0.12.0-2.i386.rpm ruby-libglade-0.12.0-2.i386.rpm ruby-panel-applet-0.12.0-2.i386.rpm ruby-pango-0.12.0-2.i386.rpm ruby-rsvg-0.12.0-2.i386.rpm ruby-gnome2-all-0.12.0-2.src.rpm ruby-gnome2-all-debuginfo-0.12.0-2.i386.rpm -jef From Nicolas.Mailhot at laPoste.net Sun Jul 31 08:31:45 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 31 Jul 2005 10:31:45 +0200 Subject: Request for review: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <20050730223420.GA2929@osiris.silug.org> References: <20050730223420.GA2929@osiris.silug.org> Message-ID: <1122798705.2633.22.camel@rousalka.dyndns.org> Le samedi 30 juillet 2005 ? 17:34 -0500, Steven Pritchard a ?crit : > > > Discussion on this died out... > > > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.1997-3.src.rpm > > And one dependency: > > > http://ftp.kspei.com/pub/steve/rpms/perl-Net-CIDR-Lite-0.18-1.src.rpm Missing perl(Test::Pod::Coverage) BR I don't feel at home enough in perl-land to approve the packages, but I'll test them and report back. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Sun Jul 31 09:20:33 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 31 Jul 2005 10:20:33 +0100 Subject: Request for review: perl-Mail-SPF-Query and perl-Net-CIDR-Lite In-Reply-To: <1122798705.2633.22.camel@rousalka.dyndns.org> References: <20050730223420.GA2929@osiris.silug.org> <1122798705.2633.22.camel@rousalka.dyndns.org> Message-ID: <1122801634.2851.135.camel@laurel.intra.city-fan.org> On Sun, 2005-07-31 at 10:31 +0200, Nicolas Mailhot wrote: > Le samedi 30 juillet 2005 ? 17:34 -0500, Steven Pritchard a ?crit : > > > > > > Discussion on this died out... > > > > > > http://ftp.kspei.com/pub/steve/rpms/perl-Mail-SPF-Query-1.1997-3.src.rpm > > > > And one dependency: > > > > > > http://ftp.kspei.com/pub/steve/rpms/perl-Net-CIDR-Lite-0.18-1.src.rpm > > Missing perl(Test::Pod::Coverage) BR > > I don't feel at home enough in perl-land to approve the packages, but > I'll test them and report back. "make test" isn't done by default due to the large number of external DNS lookups involved. So it probably needs: %{?_with_check:BuildRequires: perl(Test::Pod::Coverage)} Paul. -- Paul Howarth From andreas.bierfert at lowlatency.de Sun Jul 31 09:44:17 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 31 Jul 2005 11:44:17 +0200 Subject: Request for review/approval: libetpan (new dependency for sylpheed-claws) Message-ID: <42EC9D71.2090802@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 libetpan-0.38: A portable, efficient middleware for different kinds of mail access http://fedora.lowlatency.de/review/libetpan.spec http://fedora.lowlatency.de/review/libetpan-0.38-1.src.rpm The purpose of this mail library is to provide a portable, efficient middleware for different kinds of mail access. When using the drivers interface, the interface is the same for all kinds of mail access, remote and local mailboxes. As this is needed for sylpheed-claws 1.9.13 I would like to get this included asap. Thanks for you time. - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC7J1xQEQyPsWM8csRAqmIAJ4m7aHSys8VQiJvbA/mYABJRrBmpACgvZWg NWfhUV/dCYtMDpRNGqqn3js= =iAWP -----END PGP SIGNATURE----- From andreas.bierfert at lowlatency.de Sun Jul 31 10:17:39 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 31 Jul 2005 12:17:39 +0200 Subject: Request for review: koffice In-Reply-To: <42E81A42.7020702@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> <42E0D984.4050401@redhat.com> <42E81A42.7020702@lowlatency.de> Message-ID: <42ECA543.2000509@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok here we go, all new 1.4.1 koffice and koffice-langpack: http://fedora.lowlatency.de/review/koffice.spec http://fedora.lowlatency.de/review/koffice-1.4.1-1.src.rpm http://fedora.lowlatency.de/review/koffice-langpack.spec http://fedora.lowlatency.de/review/koffice-langpack-1.4.1-1.src.rpm - - Andreas - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC7KVDQEQyPsWM8csRAra+AJ9FPr2pli+L/XTMxlN/I1h3Y9OJfgCghhpz dD2FI4Wl5FtnbQJrN3ep6n0= =+TqL -----END PGP SIGNATURE----- From ville.skytta at iki.fi Sun Jul 31 10:19:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 13:19:32 +0300 Subject: Request for review: openvpn In-Reply-To: <1122771473.21238.163.camel@serendipity.dogma.lan> References: <20050730223014.GA2865@osiris.silug.org> <1122764302.21238.149.camel@serendipity.dogma.lan> <20050730232655.GA3696@osiris.silug.org> <1122771473.21238.163.camel@serendipity.dogma.lan> Message-ID: <1122805172.1285.14.camel@localhost.localdomain> On Sun, 2005-07-31 at 02:57 +0200, Alexander Dalloz wrote: > # build with pthread support (Experimental for OpenVPN 2.0) > %define with_pthread %{?_with_pthread:1}%{!?_with_pthread:0} > > and for %configure > %{?_with_pthread:--enable-pthread} Minor generic nit: the %define above is unused and unnecessary. From ville.skytta at iki.fi Sun Jul 31 10:24:01 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 13:24:01 +0300 Subject: Request for review: at-poke In-Reply-To: References: Message-ID: <1122805441.1285.18.camel@localhost.localdomain> On Tue, 2005-07-26 at 23:42 -0400, Jonathan Blandford wrote: > I'd like to put at-poke into extras. Hm, I see it was imported and builds requested, but I didn't see an approval message, nor a review nor anyone even volunteering to review the package... did I miss something? http://fedoraproject.org/wiki/NewPackageProcess From tcallawa at redhat.com Sun Jul 31 13:45:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 31 Jul 2005 08:45:37 -0500 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa791050730195720ce34c4@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> <20050730090415.4ffe13a6.bugs.michael@gmx.net> <604aa79105073006106c331057@mail.gmail.com> <604aa791050730195720ce34c4@mail.gmail.com> Message-ID: <1122817537.2704.16.camel@localhost.localdomain> On Sat, 2005-07-30 at 22:57 -0400, Jeff Spaleta wrote: > On 7/30/05, Jeff Spaleta wrote: > > I'm working on splitting out subpackages for each component now. > > Second draft of the src.rpm which now splits out each sub-component > from the ruby-gnome2-all tarball as a seperate binary package. > > Just a few questions I have left: > 1) not sure whether to include the previously discussed changed to > %__find_provides or not. Well, it seems as if there is good reason to do this. This is how OOo does it (to get rid of the libxmlsec1 and libdb-/libdb_ provides and requires). This goes in %setup, after applying patches. You should be able to modify the logic for ruby-gnome. find_provides="%{__find_provides}" echo "#!/bin/sh" > find-provides echo "$find_provides | grep -v libxmlsec1 | grep -v libdb- | grep -v libdb_" >> find-provides echo "exit 0" >> find-provides chmod +x find-provides %define __find_provides %{_builddir}/SRC680_m%{ooo2ver}/find-provides find_requires="%{__find_requires}" echo "#!/bin/sh" > find-requires echo "$find_requires | grep -v libxmlsec1 | grep -v libdb- | grep -v libdb_ | grep -v \(" >> find-requires echo "exit 0" >> find-requires chmod +x find-requires %define __find_requires %{_builddir}/SRC680_m%{ooo2ver}/find-requires > 2) I'm excluding .h files... should i make one big -devel package are > make seperate -devel subpackages that each pretty much includes just > .h file per -devel package. Up to you. Either one would be considered "correct". > 3)the damn sample scripts that I'm including as the %docs uses > /usr/local/bin/ruby and rpm is picking that up and adding a > requirement for /usr/loca/bin/ruby. What to do here? > a)drop the samples from the packages > b)patch the samples to use /usr/bin/ruby I vote for b, patch the samples. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jspaleta at gmail.com Sun Jul 31 13:51:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 31 Jul 2005 09:51:53 -0400 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <1122817537.2704.16.camel@localhost.localdomain> References: <604aa791050727173121bee18d@mail.gmail.com> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> <20050730090415.4ffe13a6.bugs.michael@gmx.net> <604aa79105073006106c331057@mail.gmail.com> <604aa791050730195720ce34c4@mail.gmail.com> <1122817537.2704.16.camel@localhost.localdomain> Message-ID: <604aa7910507310651690c7ae1@mail.gmail.com> On 7/31/05, Tom 'spot' Callaway wrote: > I vote for b, patch the samples. thats because you hate me. I'll get a 3rd draft out today at some point with the changes. -jef From tcallawa at redhat.com Sun Jul 31 14:08:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 31 Jul 2005 09:08:41 -0500 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <604aa7910507310651690c7ae1@mail.gmail.com> References: <604aa791050727173121bee18d@mail.gmail.com> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> <20050730090415.4ffe13a6.bugs.michael@gmx.net> <604aa79105073006106c331057@mail.gmail.com> <604aa791050730195720ce34c4@mail.gmail.com> <1122817537.2704.16.camel@localhost.localdomain> <604aa7910507310651690c7ae1@mail.gmail.com> Message-ID: <1122818921.2704.18.camel@localhost.localdomain> On Sun, 2005-07-31 at 09:51 -0400, Jeff Spaleta wrote: > On 7/31/05, Tom 'spot' Callaway wrote: > > I vote for b, patch the samples. > > thats because you hate me. Or just use sed. It should be a pretty easy loop and replace. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Sun Jul 31 14:18:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 17:18:27 +0300 Subject: Any tips or guidelines for creating ruby packages? In-Reply-To: <1122817537.2704.16.camel@localhost.localdomain> References: <604aa791050727173121bee18d@mail.gmail.com> <1122511890.2645.11.camel@localhost.localdomain> <604aa7910507271800533887d8@mail.gmail.com> <1122512805.2645.14.camel@localhost.localdomain> <604aa79105072718525d0617a4@mail.gmail.com> <1122515871.2645.16.camel@localhost.localdomain> <604aa79105072809402c436ba2@mail.gmail.com> <20050730090415.4ffe13a6.bugs.michael@gmx.net> <604aa79105073006106c331057@mail.gmail.com> <604aa791050730195720ce34c4@mail.gmail.com> <1122817537.2704.16.camel@localhost.localdomain> Message-ID: <1122819507.1285.38.camel@localhost.localdomain> On Sun, 2005-07-31 at 08:45 -0500, Tom 'spot' Callaway wrote: > This is how OOo does it (to get rid of the libxmlsec1 and libdb-/libdb_ > provides and requires). This goes in %setup, after applying patches. You > should be able to modify the logic for ruby-gnome. [...] > %define __find_provides %{_builddir}/SRC680_m%{ooo2ver}/find-provides [...] > %define __find_requires %{_builddir}/SRC680_m%{ooo2ver}/find-requires IIRC this requires also: %define _use_internal_dependency_generator 0 ...otherwise it has no effect. From bugs.michael at gmx.net Sun Jul 31 14:23:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 31 Jul 2005 16:23:43 +0200 Subject: Request for review/approval: libetpan (new dependency for sylpheed-claws) In-Reply-To: <42EC9D71.2090802@lowlatency.de> References: <42EC9D71.2090802@lowlatency.de> Message-ID: <20050731162343.44479952.bugs.michael@gmx.net> On Sun, 31 Jul 2005 11:44:17 +0200, Andreas Bierfert wrote: > libetpan-0.38: > A portable, efficient middleware for different kinds of mail access > > http://fedora.lowlatency.de/review/libetpan.spec > http://fedora.lowlatency.de/review/libetpan-0.38-1.src.rpm > > The purpose of this mail library is to provide a portable, efficient middleware > for different kinds of mail access. When using the drivers interface, the > interface is the same for all kinds of mail access, remote and local mailboxes. > > As this is needed for sylpheed-claws 1.9.13 I would like to get this included asap. > First brief look: Package is broken. libetpan.so.3.0.0 is not executable and hence not stripped, find_requires ignored it (see rpm -qpR libetpan-0.38-1.i386.rpm) and didn't create any dependencies, and debuginfo package is useless. > BuildRequires: compat-db Highly doubtful, since it is no package suitable for developing. Also: checking db.h usability... no checking db.h presence... no checking for db.h... no With BR db4-devel you would get: checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking version of Berkeley DB... version 3.x or above [...] checking for db_create() in -ldb... found > configure: WARNING: GnuTLS support disabled. We do have gnutls-devel, so this should be examined. There's a switch in the configure script (default value: auto) where you should disable GnuTLS explicitly if the support is not desired. > libetpan-config script in libetpan-devel package $ libetpan-config --libs -L/usr/lib -letpan -pthread -lssl -lcrypto -lsasl2 This creates a dependency on openssl-devel and cyrus-sasl-devel. Suggest adding them. Package summary without leading "A" is commonly considered better taste. Summary: Portable, efficient middleware for different kinds of mail access There's various libetpan API documentation in the "doc" sub-directory. From Jochen at herr-schmitt.de Sun Jul 31 20:25:20 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 31 Jul 2005 22:25:20 +0200 Subject: New Package: pdftk In-Reply-To: <1122502082.3550.35.camel@ignacio.lan> References: <20050726190544.GA7573@myhome> <1122464452.3550.26.camel@ignacio.lan> <0MKwh2-1Dxq4R1tuV-0003DJ@mrelayeu.kundenserver.de> <1122502082.3550.35.camel@ignacio.lan> Message-ID: <0MKwpI-1DzKNG0T5D-00064e@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Jul 2005 18:08:02 -0400, you wrote: >* PGP Signed by an unverified key: 07/28/05 at 00:08:02 >On Wed, 2005-07-27 at 19:51 +0200, Jochen Schmitt wrote: >> SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-2-src.rpm >> SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec > >Unfortunately including debian/copyright doesn't work as it doesn't >contain a copy of the literal text of the GPL. Please find a copy from >another source and include it as Source1. I have create a Source-RPM, which will be contains the License-Adobe.txt file in the java_libs/com/lowagie/text/pdf/fonts dir after a rpmbuild -bp and a verbarint GPL as COPYRIGHT text. The fist point is only a solution until the upstream author has included License-Adobe.txt into the tarbarr. You may found the source RPM and the SPEC file at: SRPM: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.12-3-src.rpm SPEC: http://www-herr-schmitt.de/pub/pfdtk/pdftk.spec Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQu0zu09gByurcX4MEQKlXwCg4bRZDT9L2Gi8kGK508AXtAWto2gAoNIe kJcx2aD/yL0I66qsX9JZoWp/ =4sTU -----END PGP SIGNATURE----- From Jochen at herr-schmitt.de Sun Jul 31 20:25:31 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 31 Jul 2005 22:25:31 +0200 Subject: [REPOST]New Package: highlight Message-ID: <0MKwpI-1DzKNG3LFe-00064e@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I want do introduced the following package to Fedora Extras: Description: A utility that converts sourcecode to HTML, XHTML, RTF, LaTeX, TeX, XSL-FO, XML or ANSI escape sequences with syntax highlighting. It supports several programming and markup languages. Language descriptions are configurable and support regular expressions. The utility offers indentation and reformatting capabilities. It is easily possible to create new language definitions and colour themes. SRPM: http://www.herr-schmitt.de/pub/highlight/highlight-2.4-1.src.rpm SPEC: http://www.herr-schmitt.de/pub/hightling/hightliht.spec Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.1 (Build 2185) iQA/AwUBQu0zu09gByurcX4MEQJEmwCdFYKrXYxE47qUqX2rVTJaNp66qd8AoPCM gJ18geL/jbAcyij2GBBwWS1F =vyda -----END PGP SIGNATURE----- From wtogami at redhat.com Sun Jul 31 23:14:25 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 31 Jul 2005 13:14:25 -1000 Subject: APPROVED Re: Request for review: koffice In-Reply-To: <42ECA543.2000509@lowlatency.de> References: <42C46C17.3050805@lowlatency.de> <200507211822.32303.symbiont@berlios.de> <42DFEDBD.4080904@redhat.com> <200507221154.22370.symbiont@berlios.de> <42E094EE.2020201@lowlatency.de> <42E0D984.4050401@redhat.com> <42E81A42.7020702@lowlatency.de> <42ECA543.2000509@lowlatency.de> Message-ID: <42ED5B51.8050104@redhat.com> Andreas Bierfert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ok here we go, all new 1.4.1 koffice and koffice-langpack: > > http://fedora.lowlatency.de/review/koffice.spec > http://fedora.lowlatency.de/review/koffice-1.4.1-1.src.rpm Please test for proper directory ownership as these packages are installed in dependency order. Test it using a similar procedure to this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136030#c21 Remove all koffice directories after uninstalling the old koffice package if they still exist before doing the procedure. > > http://fedora.lowlatency.de/review/koffice-langpack.spec > http://fedora.lowlatency.de/review/koffice-langpack-1.4.1-1.src.rpm > My only thought is perhaps the langpacks should not require an exact matching %{release}. By requiring only a matching %{version}, then you can independently patch either package without necessitating a zero change rebuild of the other. New langpacks are released with every new version right? After this change to Requires, I suspect your koffice is ready so APPROVED. If we find any further problems we can always rebuild. Warren Togami wtogami at redhat.com