From jwboyer at jdub.homelinux.org Fri Apr 1 02:21:02 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 31 Mar 2005 20:21:02 -0600 Subject: Suggestion: quilt Message-ID: <1112322062.12105.44.camel@jdub.homelinux.org> Howdy, I built a package for quilt that I think should be up to Extras standards. I believe I have a sponsor already, but I'm still firming some things up with my employer before submitting my papers for CVS access. Description: The scripts allow one to manage a series of patches by keeping track of the changes each patch makes. Patches can be applied, un-applied, refreshed, etc. The key philosophical concept is that your primary output is patches. Not ".c" files, not ".h" files. But patches. So patches are the first- class object here. Quilt was originally based on Andrew Morton's patch scripts published on the linux kernel mailing list a while ago, but were heavily modified since then. URL: http://savannah.nongnu.org/projects/quilt The package and spec file can be found here: http://jdub.homelinux.org/files/ thx, josh From malists at epon.ro Fri Apr 1 07:13:49 2005 From: malists at epon.ro (Marius Andreiana) Date: Fri, 01 Apr 2005 10:13:49 +0300 Subject: development package report and build request Message-ID: <1112339630.4238.17.camel@marte.biciclete.ro> After a few days of struggling with wine-20050310-1fc3winehq, I can finally report success! I've added to fedora extras development cvs the following packages and I request a build for them: - iis 8.2 (Microsoft Internet Information Server) I hope it will be included in Fedora Core 5 and by Fedora Core 7 it will be the default instead of buggy Apache I'm still working on support of ASP.NET (using mono) - iexplorer 6.1 Internet Explorer is the most critical missing piece from a decent desktop! This prevents reports I get from my users like 'Linux is slow and no multi-tasking, it can only open one window when surfing the net. Explorer opens so many so fast!' - msibuild 3.0 This was working since wine-20050105, when MSI support was added, but I was waiting for the other packages to really test it. This supports building software packages with Microsoft Software Installer instead of current rpm. So, rather than current feature-less situation when you double click a .rpm file and it installs, and you can know each file on what package belongs and it can uninstall cleanly, one can have now enterprise-level software installs: double click an .exe file, it uncompresses, it runs install, user can press Next several times (gives a feeling of interactivity), he can choose to install in /usr, in /usr/local or /prgfiles and so on. On uninstall it automatically detects what files might be used by other programs, so they can be left on the system. That's it for now, next I'll work on anti-virus and anti-spyware (FREE for personal use!) I'm CCing this to fedora-list too, I think this is important news for everybody! -- Marius Andreiana Epon -- future-proof business applications http://www.epon.ro From bugs.michael at gmx.net Fri Apr 1 09:00:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Apr 2005 11:00:15 +0200 Subject: Suggestion: quilt In-Reply-To: <1112322062.12105.44.camel@jdub.homelinux.org> References: <1112322062.12105.44.camel@jdub.homelinux.org> Message-ID: <20050401110015.671b1925.bugs.michael@gmx.net> On Thu, 31 Mar 2005 20:21:02 -0600, Josh Boyer wrote: > URL: http://savannah.nongnu.org/projects/quilt > > The package and spec file can be found here: > http://jdub.homelinux.org/files/ The separate spec file gives "permission denied". But since it's included in the src.rpm, it can be downloaded nevertheless. I seriously suggest that you delete old changelog entries from the spec file, because the authors abuse it as a program changelog. While that may work for the authors themselves, it doesn't work well if somebody else is a packager. The spec is >32 KiB already. From jwboyer at jdub.homelinux.org Fri Apr 1 12:13:13 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 01 Apr 2005 06:13:13 -0600 Subject: Suggestion: quilt In-Reply-To: <20050401110015.671b1925.bugs.michael@gmx.net> References: <1112322062.12105.44.camel@jdub.homelinux.org> <20050401110015.671b1925.bugs.michael@gmx.net> Message-ID: <1112357593.12105.46.camel@jdub.homelinux.org> On Fri, 2005-04-01 at 11:00 +0200, Michael Schwendt wrote: > On Thu, 31 Mar 2005 20:21:02 -0600, Josh Boyer wrote: > > > URL: http://savannah.nongnu.org/projects/quilt > > > > The package and spec file can be found here: > > http://jdub.homelinux.org/files/ > > The separate spec file gives "permission denied". But since it's included > in the src.rpm, it can be downloaded nevertheless. I seriously suggest > that you delete old changelog entries from the spec file, because the > authors abuse it as a program changelog. While that may work for the > authors themselves, it doesn't work well if somebody else is a packager. > The spec is >32 KiB already. Good point. Done. Updated srpm and spec file in the same location. The permissions on the spec file should be fixed now too. Sorry about that. josh From mricon at gmail.com Fri Apr 1 14:18:40 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 1 Apr 2005 09:18:40 -0500 Subject: Review: Epylog Message-ID: Hello, all: Epylog-1.0.3-1 has been committed to the devel branch. Please give it a whirl. Description: Epylog is a new log notifier and parser which runs periodically out of cron, looks at your logs, processes the entries in order to present them in a more comprehensive format, and then provides you with the output. It is written specifically with large network clusters in mind where a lot of machines (around 50 and upwards) log to the same loghost using syslog or syslog-ng. Regards, -- Konstantin Ryabitsev Zlotniks, INC From qspencer at ieee.org Fri Apr 1 17:57:20 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 01 Apr 2005 11:57:20 -0600 Subject: Packaging questions In-Reply-To: <42418D8B.80807@math.unl.edu> References: <1111176376.4628.5.camel@cutter> <20050318200947.GK19264@angus.ind.WPI.EDU> <1111386379.18284.248.camel@arena.soho.bytebot.net> <1111386782.16997.59.camel@cutter> <42418392.2030608@ieee.org> <4241860F.4030803@math.unl.edu> <1111591904.26600.61.camel@huygens> <42418D8B.80807@math.unl.edu> Message-ID: <424D8B80.8040706@ieee.org> I'm working on an RPM for GLPK (http://www.gnu.org/software/glpk/glpk.html), and I'm wondering the best approach to packaging. According to changelog notes in the Debian packages and some old discussion on the GLPK mailing list, the library is not reentrant and therefore should be built as only a static library, though some discussion on the lists in 2003 seemed to vaguely indicate that that may have changed by now. If it were even advisable, building shared libraries would require some extra hacking because the package does not support it as is (the Debian package includes only static libs). If I build it as static only, there are two approaches to packaging. One is as follows (an excerpt from a spec file posted to a GLPK mailing list): %files %defattr(-,root,root) %doc AUTHORS ChangeLog COPYING NEWS README doc %{_bindir}/* ## Note: shared libs are not built by default #%{_libdir}/lib*.so.* %files devel %defattr(-,root,root) %{_includedir}/*.h %{_libdir}/*.a There are two binaries that allow a command line interface to the library, which would be basically the only thing included, and the rest would be in the devel package. The other option is the Debian approach of putting it all in one package with no devel package. Is there a preferred way to do this? -Quentin From rdieter at math.unl.edu Fri Apr 1 18:00:06 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 01 Apr 2005 12:00:06 -0600 Subject: Packaging questions In-Reply-To: <424D8B80.8040706@ieee.org> References: <1111176376.4628.5.camel@cutter> <20050318200947.GK19264@angus.ind.WPI.EDU> <1111386379.18284.248.camel@arena.soho.bytebot.net> <1111386782.16997.59.camel@cutter> <42418392.2030608@ieee.org> <4241860F.4030803@math.unl.edu> <1111591904.26600.61.camel@huygens> <42418D8B.80807@math.unl.edu> <424D8B80.8040706@ieee.org> Message-ID: <424D8C26.5010006@math.unl.edu> Quentin Spencer wrote: > I'm working on an RPM for GLPK ... > There are two binaries that allow a command line interface to the > library, which would be basically the only thing included, and the rest > would be in the devel package. The other option is the Debian approach > of putting it all in one package with no devel package. Is there a > preferred way to do this? Personally, I prefer the former approach, so that developer packages can always be easily identified by -devel -- Rex From ville.skytta at iki.fi Fri Apr 1 20:40:19 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 01 Apr 2005 23:40:19 +0300 Subject: Wiki borked? Message-ID: <1112388019.23456.1.camel@bobcat.mine.nu> I tried to edit FC[34]Status in Wiki, but after clicking "Save Changes", my changes are silently lost. Tried with both Firefox and Konqueror, same results with both. Anyone else seeing this? From skvidal at phy.duke.edu Fri Apr 1 20:43:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 01 Apr 2005 15:43:34 -0500 Subject: Wiki borked? In-Reply-To: <1112388019.23456.1.camel@bobcat.mine.nu> References: <1112388019.23456.1.camel@bobcat.mine.nu> Message-ID: <1112388214.3114.13.camel@cutter> On Fri, 2005-04-01 at 23:40 +0300, Ville Skytt? wrote: > I tried to edit FC[34]Status in Wiki, but after clicking "Save Changes", > my changes are silently lost. Tried with both Firefox and Konqueror, > same results with both. Anyone else seeing this? the apache rewrite rule I used to fix the damned _2f stuff yesterday screwed up the SubPages. I turned it off, it should be fine now. I need to update the wiki to 1.3.4 soon anyway. sorry for the hassle. -sv From thm at duke.edu Fri Apr 1 21:29:29 2005 From: thm at duke.edu (Hunter Matthews) Date: Fri, 01 Apr 2005 16:29:29 -0500 Subject: Request for Review: bioperl and its dependancies Message-ID: <1112390969.2932.142.camel@jade.biology.duke.edu> bioperl is a popular perl module for bioinformatics work. It has a number of dependancies, some of which are already in FC-3 or FE - the rest are here. All of the following are at http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ perl-bioperl Descrption: Bioperl is a package of public domain Perl tools for computational molecular biology. Its non-FC3/non-FE dependancies are: perl-GD-SVG GD::SVG seamlessly enables the scalable vector graphics (SVG) output from scripts written using GD. It accomplishes this by translating GD functions into SVG functions. perl-Graph This is Graph, a Perl module for dealing with graphs, the abstract data structures. (If you were looking for pie charts, I'm sorry.) perl-Heap This is a collection of routines for managing a heap data structure. There are two major components: a heap component, and an element component. perl-MIME-Lite MIME::Lite is intended as a simple, standalone module for generating (not parsing!) MIME messages... specifically, it allows you to output a simple, decent single- or multi-part message with text or binaryattachments. It does not require that you have the Mail:: or MIME:: modules installed. perl-SOAP-Lite SOAP::Lite for Perl is a collection of Perl modules which provides a simple and lightweight interface to the Simple Object Access Protocol (SOAP) both on client and server side. perl-SVG SVG.pm is a perl extention to generate stand-alone or inline SVG (scaleable vector graphics) images using the W3C SVG xml recommendation. perl-Text-Shellwords This is a thin wrapper around the shellwords.pl package, which comes preinstalled with Perl. This module imports a single subroutine, shellwords(). The shellwords() routine parses lines of text and returns a set of tokens using the same rules that the Unix shell does for its command-line arguments. Tokens are separated by whitespace, and can be delimited by single or double quotes. The module also respects backslash escapes. perl-XML-Writer XML::Writer is a simple Perl module for writing XML documents: it takes care of constructing markup and escaping data correctly, and by default, it also performs a significant amount of well-formedness checking on the output, to make certain (for example) that start and end tags match, that there is exactly one document element, and that there are not duplicate attribute names. Please be a bit gentle with any perlisms - I'm the packager, but am not really a perl expert. -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From sheltren at cs.ucsb.edu Sat Apr 2 03:00:05 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 01 Apr 2005 19:00:05 -0800 Subject: Review: Epylog In-Reply-To: Message-ID: Hi Icon, I'm no expert, but it looks good to me. Builds cleanly on my FC4 box. I am a bit confused about the --with-lynx passed to configure - what does that do? I erased the elinks package and it still seemed to build fine with that option... BTW, I really like the collapsing login feature :) -Jeff On 4/1/05 6:18 AM, "Konstantin Ryabitsev" wrote: > Hello, all: > > Epylog-1.0.3-1 has been committed to the devel branch. Please give it a whirl. > > Description: > Epylog is a new log notifier and parser which runs periodically out of > cron, looks at your logs, processes the entries in order to present > them in a more comprehensive format, and then provides you with the > output. It is written specifically with large network clusters in mind > where a lot of machines (around 50 and upwards) log to the same > loghost using syslog or syslog-ng. > > Regards, From skvidal at phy.duke.edu Sat Apr 2 03:04:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 01 Apr 2005 22:04:25 -0500 Subject: Review: Epylog In-Reply-To: References: Message-ID: <1112411065.7558.0.camel@cutter> On Fri, 2005-04-01 at 19:00 -0800, Jeff Sheltren wrote: > Hi Icon, I'm no expert, but it looks good to me. Builds cleanly on my FC4 > box. I am a bit confused about the --with-lynx passed to configure - what > does that do? I erased the elinks package and it still seemed to build fine > with that option... > > BTW, I really like the collapsing login feature :) lynx != elinks -sv From mricon at gmail.com Sat Apr 2 03:17:15 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 1 Apr 2005 22:17:15 -0500 Subject: Review: Epylog In-Reply-To: References: Message-ID: On Apr 1, 2005 10:00 PM, Jeff Sheltren wrote: > Hi Icon, I'm no expert, but it looks good to me. Builds cleanly on my FC4 > box. I am a bit confused about the --with-lynx passed to configure - what > does that do? I erased the elinks package and it still seemed to build fine > with that option... It's a sane default setting. Epylog has an option of generating text-only reports (as opposed to just HTML reports), but to go from html to text it requires a lynx-compatible browser, like elinks, w3m, or, well, lynx. By default, only HTML reports are generated, which is why there is no elinks dependency in the RPM, but should folks desire to have text reports, they are much more likely to have elinks installed than lynx or w3m. Besides, without that option specified, the configure script will try to find it on the system and error out if neither lynx, links, nor w3m are found (which is probably a silly behavior in itself, I'll look into modifying that). Regards, -- Konstantin Ryabitsev Zlotniks, INC From sheltren at cs.ucsb.edu Sat Apr 2 04:52:39 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 01 Apr 2005 20:52:39 -0800 Subject: Review: Epylog In-Reply-To: <1112411065.7558.0.camel@cutter> Message-ID: On 4/1/05 7:04 PM, "seth vidal" wrote: > lynx != elinks > > -sv > True, but the configure option is '--with-lynx=%{_bindir}/links', and that is provided by the elinks package. -Jeff From jeff at ocjtech.us Sat Apr 2 05:14:53 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 01 Apr 2005 23:14:53 -0600 Subject: Pre-Review: Asterisk Message-ID: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> Hi, I've put together SRPMS for Asterisk and dependencies. The SRPMs and .spec files can be found at . These packages aren't quite ready for import into CVS yet IMHO as I was hoping to get some feedback from the community. Specifically I'm wondering what the best way to package kernel modules for Fedora Extras would be. Yes, it would be nice to get these kernel drivers into Linus' tree but that's not practical at the moment. 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 dwmw2 at infradead.org Sat Apr 2 12:56:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 Apr 2005 13:56:14 +0100 Subject: [Asterisk-Dev] SRPMs for Fedora Extras In-Reply-To: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> References: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> Message-ID: <1112446575.3899.151.camel@localhost.localdomain> On Fri, 2005-04-01 at 23:39 -0600, Jeffrey C. Ollie wrote: > > I've put together some SRPMs for Asterisk that I hope to get imported > into Fedora Extras. I'd appreciate any feedback on the packaging that > you have. The SRPMS can be found at . 403. I'd like to see Asterisk in Extras. Also capi4k-utils, chan_capi, and spandsp. I should finish beating chan_bluetooth into shape and that can be packaged too; I do at least have it doing duplex audio fairly sanely now. I'd like to see mISDN packaged but that wants to go into Linus' kernel and hence into the standard kernel RPM -- and before that can happen, it needs to stop being quite so broken. The zaptel kernel parts want feeding to Linus too, assuming they're in a good enough state for that -- I haven't looked at them at all yet. If possible, we need to lose the dependency which chan_iax2 has on the zap driver. If it's only used for timing, we should investigate the POSIX timer functionality which is available with newer kernel/glibc. -- dwmw2 From nphilipp at redhat.com Sat Apr 2 13:13:03 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 02 Apr 2005 15:13:03 +0200 Subject: Candidate for Extras: evolution-groupdav (Noodle project connector for OpenGroupware) In-Reply-To: <1112235762.1505.9.camel@cassandra.boston.redhat.com> References: <1112235762.1505.9.camel@cassandra.boston.redhat.com> Message-ID: <1112447584.28994.16.camel@gibraltar.stuttgart.redhat.com> On Wed, 2005-03-30 at 21:22 -0500, David Malcolm wrote: > I had a go at packaging the Noodle projects's connector for Evolution > for OoenGroupware, you can see the results here: > > http://people.redhat.com/dmalcolm/noodle/ > > Would this be a good candidate for Extras? I'd say yes. I took the "quick tour", i.e. looked at the spec file only (not having OGO installed): - I'm not sure about this one: [...] %define blabla_version 0.5 [...] Requires: blabla >= %blabla_version [...] BuildRequires: blabla-devel >= %blabla_version [...] Ideally I'd rather only "BuildRequires: blabla-devel >= 0.5" and let automatic dependency tracking sort out the rest. If that isn't sufficient, I guess this should be solved in rpmbuild and not the spec files (only MO). Probably "Requires: evolution-data-server ..." rather than "Requires: evolution-data-server-devel ... " if you really must ;-), the same goes for libgnomeui. - Some people are more comfy with "BuildRoot: %{_tmppath}/%{name}-%{version}-root-%(%__id_u -n)" - Maybe "Source: evolution-groupdav-%{version}.tar.gz" --> "Source0: http://noodle.yacoi.com/devel/downloads/evolution-groupdav/evolution-groupdav-%{version}.tar.gz" - Cosmetics: Make %description a whole sentence, e.g. "Evolution- groupdav contains a plugin and backends...." - You should run "make" in %build, not only "make DESTDIR=... install" in %install (then use %makeinstall if possible) - Don't "[ -n "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != / ] && rm -rf $RPM_BUILD_ROOT", just "rm -rf $RPM_BUILD_ROOT" (or even "rm -rf % buildroot", what suits you better), rpmbuild will take care of that %buildroot/$RPM_BUILD_ROOT isn't "/" - "BuildRequires: findutils" if you use the find command HTH, 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 nphilipp at redhat.com Sat Apr 2 13:18:04 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 02 Apr 2005 15:18:04 +0200 Subject: Packaging questions In-Reply-To: <424D8B80.8040706@ieee.org> References: <1111176376.4628.5.camel@cutter> <20050318200947.GK19264@angus.ind.WPI.EDU> <1111386379.18284.248.camel@arena.soho.bytebot.net> <1111386782.16997.59.camel@cutter> <42418392.2030608@ieee.org> <4241860F.4030803@math.unl.edu> <1111591904.26600.61.camel@huygens> <42418D8B.80807@math.unl.edu> <424D8B80.8040706@ieee.org> Message-ID: <1112447884.28994.19.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-04-01 at 11:57 -0600, Quentin Spencer wrote: > I'm working on an RPM for GLPK > (http://www.gnu.org/software/glpk/glpk.html), and I'm wondering the best > approach to packaging. According to changelog notes in the Debian > packages and some old discussion on the GLPK mailing list, the library > is not reentrant and therefore should be built as only a static library, I don't know what being (non-)reentrant would have to do with being a shared or static library. Can you elaborate? 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 dwmw2 at infradead.org Sat Apr 2 13:00:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 2 Apr 2005 06:00:31 -0700 Subject: [Asterisk-Dev] SRPMs for Fedora Extras In-Reply-To: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> References: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> Message-ID: <000001c53783$f3e71ba0$6500a8c0@Abidia.local> On Fri, 2005-04-01 at 23:39 -0600, Jeffrey C. Ollie wrote: > > I've put together some SRPMs for Asterisk that I hope to get imported > into Fedora Extras. I'd appreciate any feedback on the packaging that > you have. The SRPMS can be found at . 403. I'd like to see Asterisk in Extras. Also capi4k-utils, chan_capi, and spandsp. I should finish beating chan_bluetooth into shape and that can be packaged too; I do at least have it doing duplex audio fairly sanely now. I'd like to see mISDN packaged but that wants to go into Linus' kernel and hence into the standard kernel RPM -- and before that can happen, it needs to stop being quite so broken. The zaptel kernel parts want feeding to Linus too, assuming they're in a good enough state for that -- I haven't looked at them at all yet. If possible, we need to lose the dependency which chan_iax2 has on the zap driver. If it's only used for timing, we should investigate the POSIX timer functionality which is available with newer kernel/glibc. -- dwmw2 _______________________________________________ Asterisk-Dev mailing list Asterisk-Dev at lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev From ivazquez at ivazquez.net Sat Apr 2 14:02:19 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 02 Apr 2005 09:02:19 -0500 Subject: Packaging questions In-Reply-To: <1112447884.28994.19.camel@gibraltar.stuttgart.redhat.com> References: <1111176376.4628.5.camel@cutter> <20050318200947.GK19264@angus.ind.WPI.EDU> <1111386379.18284.248.camel@arena.soho.bytebot.net> <1111386782.16997.59.camel@cutter> <42418392.2030608@ieee.org> <4241860F.4030803@math.unl.edu> <1111591904.26600.61.camel@huygens> <42418D8B.80807@math.unl.edu> <424D8B80.8040706@ieee.org> <1112447884.28994.19.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1112450539.18764.6.camel@ignacio.ignacio.lan> On Sat, 2005-04-02 at 15:18 +0200, Nils Philippsen wrote: > On Fri, 2005-04-01 at 11:57 -0600, Quentin Spencer wrote: > > I'm working on an RPM for GLPK > > (http://www.gnu.org/software/glpk/glpk.html), and I'm wondering the best > > approach to packaging. According to changelog notes in the Debian > > packages and some old discussion on the GLPK mailing list, the library > > is not reentrant and therefore should be built as only a static library, > > I don't know what being (non-)reentrant would have to do with being a > shared or static library. Can you elaborate? If the library is built as shared then multiple applications can enter its code space at the same time. Being non-reentrant most if not all of these applications would break. If built as a static library then each app has its own private copy of the library, therefore there is practically no chance that multiple applications using the library will interfere with each other. Having said that, IMO the developer should be severely knocked for having written a non-reentrant library in this day and age. -- 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 mitr at volny.cz Sat Apr 2 14:04:50 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 2 Apr 2005 16:04:50 +0200 Subject: Packaging questions In-Reply-To: <1112450539.18764.6.camel@ignacio.ignacio.lan> References: <1111386379.18284.248.camel@arena.soho.bytebot.net> <1111386782.16997.59.camel@cutter> <42418392.2030608@ieee.org> <4241860F.4030803@math.unl.edu> <1111591904.26600.61.camel@huygens> <42418D8B.80807@math.unl.edu> <424D8B80.8040706@ieee.org> <1112447884.28994.19.camel@gibraltar.stuttgart.redhat.com> <1112450539.18764.6.camel@ignacio.ignacio.lan> Message-ID: <20050402140446.GA17777@chrys.ms.mff.cuni.cz> On Sat, Apr 02, 2005 at 09:02:19AM -0500, Ignacio Vazquez-Abrams wrote: > If the library is built as shared then multiple applications can enter > its code space at the same time. Being non-reentrant most if not all of > these applications would break. Linux is not Windows 3.1; a shared library does not have its "data segment" shared across all processes that use the library (unless it explicitly creates a shared memory mapping). Mirek From jeff at ocjtech.us Sat Apr 2 13:58:00 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 02 Apr 2005 07:58:00 -0600 Subject: [Asterisk-Dev] SRPMs for Fedora Extras In-Reply-To: <1112446575.3899.151.camel@localhost.localdomain> References: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> <1112446575.3899.151.camel@localhost.localdomain> Message-ID: <1112450280.5677.43.camel@lt16586.campus.dmacc.edu> On Sat, 2005-04-02 at 13:56 +0100, David Woodhouse wrote: > On Fri, 2005-04-01 at 23:39 -0600, Jeffrey C. Ollie wrote: > > > > I've put together some SRPMs for Asterisk that I hope to get imported > > into Fedora Extras. I'd appreciate any feedback on the packaging that > > you have. The SRPMS can be found at . > > 403. Doh! Serves me right for not testing first. > I'd like to see Asterisk in Extras. Yay! > Also capi4k-utils, chan_capi, and Yep. > spandsp. There might be a problem with patents. See . That said, I do have a package for SpanDSP but it's not linked into my Asterisk packages (due to the patent issues). > I should finish beating chan_bluetooth into shape and that can > be packaged too; I do at least have it doing duplex audio fairly sanely > now. Yep. > I'd like to see mISDN packaged but that wants to go into Linus' kernel > and hence into the standard kernel RPM -- and before that can happen, it > needs to stop being quite so broken. > > The zaptel kernel parts want feeding to Linus too, assuming they're in a > good enough state for that -- I haven't looked at them at all yet. I agree that having kernel drivers in the stock kernels is a good thing. The main question is would Digium support that. > If possible, we need to lose the dependency which chan_iax2 has on the > zap driver. If it's only used for timing, we should investigate the > POSIX timer functionality which is available with newer kernel/glibc. Agreed. 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 jeff at ocjtech.us Sat Apr 2 14:28:08 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 02 Apr 2005 08:28:08 -0600 Subject: Pre-Review: Asterisk In-Reply-To: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> Message-ID: <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> On Fri, 2005-04-01 at 23:14 -0600, Jeffrey C. Ollie wrote: > > Specifically I'm wondering what the best way to package > kernel modules for Fedora Extras would be. Yes, it would be nice to get > these kernel drivers into Linus' tree but that's not practical at the > moment. David Woodhouse asked me to clarify this statement. When I said that getting the Zaptel kernel drivers into Linus' tree wasn't practical at the moment I was speaking mostly about getting the cooperation of the original authors (Digium, www.digium.com) in maintaining the drivers in the kernel tree. There is also the matter of the time it would take to have the drivers reviewed by Linus, et. al., get into a released kernel, get the new kernel packaged up for Fedora, etc., etc. and I'm anxious (as I'm sure many are) to get Asterisk into Fedora Extras. So, until such time as the Zaptel drivers get into the stock kernel, I'd like to have the drivers packaged separately. Also, it is true that the Zaptel drivers are not required to run Asterisk you lose some significant functionality, including meetme conferences. 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 dwmw2 at infradead.org Sat Apr 2 14:49:06 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 Apr 2005 15:49:06 +0100 Subject: [Asterisk-Dev] SRPMs for Fedora Extras In-Reply-To: <1112450280.5677.43.camel@lt16586.campus.dmacc.edu> References: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> <1112446575.3899.151.camel@localhost.localdomain> <1112450280.5677.43.camel@lt16586.campus.dmacc.edu> Message-ID: <1112453347.3899.157.camel@localhost.localdomain> On Sat, 2005-04-02 at 07:58 -0600, Jeffrey C. Ollie wrote: > There might be a problem with patents. See > . That seems to be saying that there is _not_ a problem with patents. -- dwmw2 From riel at redhat.com Sat Apr 2 17:47:34 2005 From: riel at redhat.com (Rik van Riel) Date: Sat, 2 Apr 2005 12:47:34 -0500 (EST) Subject: Pre-Review: Asterisk In-Reply-To: <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> Message-ID: On Sat, 2005-04-02 at 08:28:08 -0600, Jeffrey C. Ollie wrote: > So, until such time as the Zaptel drivers get into the stock kernel, I'd > like to have the drivers packaged separately. Agreed, it's better to have the drivers in Fedora Extras for now, than not at all - and carrying around tons of extra drivers in the Fedora Core kernel just isn't going to happen, there are enough patches already ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From tcallawa at redhat.com Sat Apr 2 18:05:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 02 Apr 2005 12:05:19 -0600 Subject: Pre-Review: Asterisk In-Reply-To: References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> Message-ID: <1112465119.15642.16.camel@localhost.localdomain> On Sat, 2005-04-02 at 12:47 -0500, Rik van Riel wrote: > On Sat, 2005-04-02 at 08:28:08 -0600, Jeffrey C. Ollie wrote: > > > So, until such time as the Zaptel drivers get into the stock kernel, I'd > > like to have the drivers packaged separately. > > Agreed, it's better to have the drivers in Fedora Extras > for now, than not at all - and carrying around tons of > extra drivers in the Fedora Core kernel just isn't going > to happen, there are enough patches already ;) Unfortunately, there is no sane way to deal with kernel-module addon packages yet. Ville has been working pretty hard to cover some of them, but there is still at least one big issue: We can't cleanly upgrade kernel-module addon packages without scorching the earth. This is pretty vital, if we ever want to fix bugs in addon drivers without waiting for the next kernel to come out. Lets say that we have two kernel packages installed, and two kernel-module-afs packages that match them. Then we need to upgrade the kernel-module-afs packages. Problem is that we can't use -i or -U here. -i won't work because there are already installed versions. -U won't work because it will remove all existing versions and try to put in one kernel-module-afs package (rather than updating them both like we want). There are several ways to hack around this issue. We could make each package have a unique name by cramming the kernel uname -r in the addon package name, but thats hideous. It breaks all our ownership, bugzilla, and CVS infrastructure. We could build in a horrible workaround inside yum, but then we'd need to do the same for every packaging delivery system that people want to use (yum, apt, smart, etc). Rpm really needs to be able do this natively. Kernels get installed with -i today. kernel-module-* needs to get installed with a new mode, where if kernel-module-foo-2.6.10-%{release} is installed, and kernel-module-foo-2.6.10-%{release+1} exists, then only kernel-module-foo-2.6.10-%{release} gets upgraded (and not kernel-module-foo-2.6.9-%{release}, unless an upgrade for it exists, and yum/apt/whatever can take care of it then, using the same mechanism). Sortof a "upgrade only the installed package with the same %{version}" flag. -S for same. :) If no installed package with the same %{version} exists, fallback to -i logic. Let the %{version} be the kernel version. I haven't had the time to even start looking at rpm's code to work on making this possible, but its a safe bet that we won't have this done by FC4, unless people start hacking it right now. Is anyone interested in taking this challenge up? ~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 steve at silug.org Sat Apr 2 18:06:53 2005 From: steve at silug.org (Steven Pritchard) Date: Sat, 2 Apr 2005 12:06:53 -0600 Subject: Pre-Review: Asterisk In-Reply-To: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> Message-ID: <20050402180653.GA15636@osiris.silug.org> On Fri, Apr 01, 2005 at 11:14:53PM -0600, Jeffrey C. Ollie wrote: > I've put together SRPMS for Asterisk and > dependencies. The SRPMs and .spec files can be found at > . These packages aren't quite ready > for import into CVS yet IMHO as I was hoping to get some feedback from > the community. Specifically I'm wondering what the best way to package > kernel modules for Fedora Extras would be. Yes, it would be nice to get > these kernel drivers into Linus' tree but that's not practical at the > moment. I've been working on Asterisk packages for a while... https://bugzilla.fedora.us/show_bug.cgi?id=983 The last couple of builds I did for a client are here: http://apt.kspei.com/fedora/3/i386/SRPMS.kspei/ The kernel modules built from the zaptel package are built basically the same way as my kernel-module-hostap (hostap-driver) package that never quite made it through fedora.us QA. I've been waiting for the really-really-really-final word on the Fedora-approved method for packaging kernel modules to make any changes. 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 jeff at ocjtech.us Sat Apr 2 19:25:29 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 02 Apr 2005 13:25:29 -0600 Subject: [Asterisk-Dev] SRPMs for Fedora Extras In-Reply-To: <1112453347.3899.157.camel@localhost.localdomain> References: <1112420381.5677.25.camel@lt16586.campus.dmacc.edu> <1112446575.3899.151.camel@localhost.localdomain> <1112450280.5677.43.camel@lt16586.campus.dmacc.edu> <1112453347.3899.157.camel@localhost.localdomain> Message-ID: <1112469930.5677.71.camel@lt16586.campus.dmacc.edu> On Sat, 2005-04-02 at 15:49 +0100, David Woodhouse wrote: > On Sat, 2005-04-02 at 07:58 -0600, Jeffrey C. Ollie wrote: > > There might be a problem with patents. See > > . > > That seems to be saying that there is _not_ a problem with patents. If you read it optimistically. Tzafrir Cohen mentioned on the asterisk-devel list that SpanDSP is in Debian. May be worth a search of the debian lists to see if they have discussed the issue there. FWIW, I have already packaged SpanDSP and it's not hard to add the Rx/TxFAX apps to Asterisk. 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 skvidal at phy.duke.edu Sat Apr 2 21:52:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 02 Apr 2005 16:52:31 -0500 Subject: Review: Epylog In-Reply-To: References: Message-ID: <1112478752.9017.2.camel@cutter> > Description: > Epylog is a new log notifier and parser which runs periodically out of ok, epylog has been around for a couple of years-or-so now. It's not new. :) -sv From michal at harddata.com Sat Apr 2 22:17:48 2005 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 2 Apr 2005 15:17:48 -0700 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112465119.15642.16.camel@localhost.localdomain>; from tcallawa@redhat.com on Sat, Apr 02, 2005 at 12:05:19PM -0600 References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> Message-ID: <20050402151748.A28375@mail.harddata.com> On Sat, Apr 02, 2005 at 12:05:19PM -0600, Tom 'spot' Callaway wrote: > > Unfortunately, there is no sane way to deal with kernel-module addon > packages yet. ..... > > There are several ways to hack around this issue. We could make each > package have a unique name by cramming the kernel uname -r in the addon > package name, External kernel modules are a given kernel specific. One would think that should be reflected in a package name, or maybe better "identifier", or otherwise you have quick descent to madness in a system maitenance. > but thats hideous. Hm, why really hideous? Any better proposals from a point of view of a system user? > It breaks all our ownership, bugzilla, > and CVS infrastructure. That indeed could be a serious problem but maybe there are ways to fix that? It sounds like you are looking at the issue from the wrong end; possibly a false impression. > where if kernel-module-foo-2.6.10-%{release} > is installed, and kernel-module-foo-2.6.10-%{release+1} exists, then > only kernel-module-foo-2.6.10-%{release} gets upgraded (and not > kernel-module-foo-2.6.9-%{release}, It does not seem to be good enough in this form. If you happen to have kernels 2.6.10-%{release} and 2.6.10-%{release+1} installed in parallel then you need modules for both. You may also have smp and non-smp and maybe something more. Or you mean different releases of module packages for the same kernel? Then "2.6.10" is far from sufficient. You would need a kernel version, kernel release and a module release somewhere in this logic and quite a bit of change in a supporting infrastructure if you want to avoid an existing practice of making a kernel version and a kernel release a part of a module package name. The trouble is that various existing tools all over the place use these 'n-v-r' package identifiers and breaking that expectation does not sound like a very exciting prospect. Hacking CVS and bugzilla makes the problem at least limited to more or less one location. Some "special" names with a "variable" part by a convention, for example? Do I miss something? Michal From tcallawa at redhat.com Sat Apr 2 22:56:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 02 Apr 2005 16:56:01 -0600 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <20050402151748.A28375@mail.harddata.com> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> Message-ID: <1112482561.15642.39.camel@localhost.localdomain> On Sat, 2005-04-02 at 15:17 -0700, Michal Jaegermann wrote: > On Sat, Apr 02, 2005 at 12:05:19PM -0600, Tom 'spot' Callaway wrote: > > > > Unfortunately, there is no sane way to deal with kernel-module addon > > packages yet. > ..... > > > > There are several ways to hack around this issue. We could make each > > package have a unique name by cramming the kernel uname -r in the addon > > package name, > > External kernel modules are a given kernel specific. One would > think that should be reflected in a package name, or maybe better > "identifier", or otherwise you have quick descent to madness in a > system maitenance. I agree. External modules are a given kernel specific. They should identify which kernel they are for. However, this should not be done in %{name}. Version is a more appropriate place for this. So, we would have: Name: kernel-module-foo Version: 2.6.10_3smp Release: 1 > It does not seem to be good enough in this form. If you happen to > have kernels 2.6.10-%{release} and 2.6.10-%{release+1} installed in > parallel then you need modules for both. You may also have smp and > non-smp and maybe something more. I think I oversimplified the example to show the point. :) > Or you mean different releases of > module packages for the same kernel? Yes. Let me expand on my example. I have three kernel packages installed: kernel-2.6.10-2 kernel-smp-2.6.10-2 kernel-2.6.10-3 Each of these has a kernel-module-foo package installed alongside it: kernel-module-foo-2.6.10_2-1 kernel-module-foo-2.6.10_2smp-1 kernel-module-foo-2.6.10_3-1 Now, I (being the illustrious maintainer of kernel-module-foo) discover a nasty bug in the source, which I fix, and want to push a new release of the package, -2. I create the following new packages: kernel-module-foo-2.6.10_2-2 kernel-module-foo-2.6.10_2smp-2 kernel-module-foo-2.6.10_3-2 But now, when I hand these to rpm, what do I do? If I try to perform a -i, kernel-module-foo is already installed. If I try to perform a -U, kernel-module-foo conflicts with kernel-module-foo, it upgrades the largest item, and get rid of all the other kernel-module-foo packages it sees. Which leaves us with only kernel-module-foo-2.6.10_3-2 installed. As I said before, we can skirt this problem if we overload the %{name} and put the kernel version there. However, this means that in CVS, we'd have separate branches for every possible kernel version, bugzilla would have entries for every possible kernel version. Its bad, and we shouldn't do it. We need to teach rpm to perform the following transaction (ignoring normal dependency checks): - package kernel-module-foo-2.6.10_2-1, kernel-module-foo-2.6.10_2smp-1, and kernel-module-foo-2.6.10_3-1 are installed (-i will permit this). - user asks for packages kernel-module-foo-2.6.10_2-2, kernel-module-foo-2.6.10_2smp-2, and kernel-module-foo-2.6.10_3-2 to be installed. - rpm looks for existing packages which match %{name}-%{version} for each of these pending update packages. - if found, then compare %{release} with that existing %{name}-%{version} package - if %{release} of pending update is greater than existing, then upgrade ONLY that existing package with same %{name}-%{update} - else, if %{release} of pending update is same as existing, then compare epoch - if epoch of pending update is higher, then upgrade ONLY that existing package with same %{name}-%{update} - else, if %{release} of pending update is lower than existing, then exit with error. - else, if not found, perform standard -i operation on pending update package. Does that make it more clear? :) ~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 michal at harddata.com Sun Apr 3 02:24:56 2005 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 2 Apr 2005 19:24:56 -0700 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112482561.15642.39.camel@localhost.localdomain>; from tcallawa@redhat.com on Sat, Apr 02, 2005 at 04:56:01PM -0600 References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> Message-ID: <20050402192456.A748@mail.harddata.com> On Sat, Apr 02, 2005 at 04:56:01PM -0600, Tom 'spot' Callaway wrote: > > Yes. Let me expand on my example. > > I have three kernel packages installed: > > kernel-2.6.10-2 > kernel-smp-2.6.10-2 > kernel-2.6.10-3 > > Each of these has a kernel-module-foo package installed alongside it: > > kernel-module-foo-2.6.10_2-1 > kernel-module-foo-2.6.10_2smp-1 > kernel-module-foo-2.6.10_3-1 So far so good. The only thing is that you want this kernel version id squeeze into a package version part while as for now people doing that have to make it a part of a name. There is, of course, this problem that during development a module source code may have its own version as well but one can possibly overload a release part to get around the issue. > > We need to teach rpm to perform the following transaction (ignoring > normal dependency checks): That is this tricky step. It is not only a question of various rpm releases which users will try to apply to that all over the world but also various releated more-or-less official tools which are widely used. Seems quite a touchy issue to me and I am not sure how realistic are expectation that it is possibly to have not too rough transition (if any at all). I do not mind to be convinced otherwise but I do have doubts. > > - if %{release} of pending update is greater than existing, then > upgrade ONLY that existing package with same %{name}-%{update} ^^^^ Hm, some new entity showed up here. > Does that make it more clear? :) You goals are clear but now you have to find a way to distinguish packages which require such special treatment from those who are handled as upto now. Here we start into some twisty passages as far as I can tell. A special tag? Some extra part of a name? Michal From jimhayward at earthlink.net Sun Apr 3 03:23:14 2005 From: jimhayward at earthlink.net (Jim Hayward) Date: Sat, 02 Apr 2005 19:23:14 -0800 Subject: [Kind of OT] Bluefish pre 1.0.1 snapshots Message-ID: <1112498594.11144.46.camel@garfield.linux.localdomain> Hi all, I currently working on towards the Bluefish 1.0.1 release (mostly just bug fixes). As an effort to get more bug testers for these snapshots I would like to get these packaged for FC3. However I'm currently running a modified FC3 system that isn't suitable for making packages. I'm looking for a volunteer to package these snapshots for FC3. The latest Bluefish pre1.0.1 snapshot is available below. http://linuxexperience.net/bluefish/snapshots/bluefish-pre1.0.1-2005502-1.tar.bz2 MD5SUM 52dcea3f5340270e34311e8eee4a7786 Please feel free to contact me off the list with bug reports, etc, for these snapshots. Regards, Jim H -- Jim Hayward GPG Key available at: http://keyserver.noreply.org gpg --recv-keys --keyserver keyserver.noreply.org 0x85A92DCC GPG Fingerprint: 1AA9 AEC9 BFDF FF7A E4F8 90C7 4947 3A41 85A9 2DCC -------------- 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 Sun Apr 3 04:43:27 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 02 Apr 2005 22:43:27 -0600 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <20050402192456.A748@mail.harddata.com> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050402192456.A748@mail.harddata.com> Message-ID: <1112503407.15642.52.camel@localhost.localdomain> On Sat, 2005-04-02 at 19:24 -0700, Michal Jaegermann wrote: > On Sat, Apr 02, 2005 at 04:56:01PM -0600, Tom 'spot' Callaway wrote: > > > > Yes. Let me expand on my example. > > > > I have three kernel packages installed: > > > > kernel-2.6.10-2 > > kernel-smp-2.6.10-2 > > kernel-2.6.10-3 > > > > Each of these has a kernel-module-foo package installed alongside it: > > > > kernel-module-foo-2.6.10_2-1 > > kernel-module-foo-2.6.10_2smp-1 > > kernel-module-foo-2.6.10_3-1 > > So far so good. The only thing is that you want this kernel > version id squeeze into a package version part while as for > now people doing that have to make it a part of a name. I'm not sure I know what you're saying here, but I don't want to put kernel versioning in %{name}. > There is, of course, this problem that during development a module > source code may have its own version as well but one can possibly > overload a release part to get around the issue. I don't think we care. Bump the release if a newer version of the module comes out. :) Either way, that issue is minor. > > We need to teach rpm to perform the following transaction (ignoring > > normal dependency checks): > > That is this tricky step. It is not only a question of various > rpm releases which users will try to apply to that all over the > world but also various releated more-or-less official tools which > are widely used. Well, I never said it would be easy. The nice thing about Fedora Extras is that we can lay new foundations and build off of them, rather than making ugly hacks for backwards compatibility. We didn't do kernel-module-* packages for FC3, FC4 would be a good place to start. (And if we wanted to do it for FC3, we could always errata rpm and Require that version of rpm). Otherwise, we have to hack each and every possible tool. If we do it in rpm, then the tools at least have a standardized method to perform the operation in the future. > You goals are clear but now you have to find a way to distinguish > packages which require such special treatment from those who > are handled as upto now. Here we start into some twisty passages > as far as I can tell. A special tag? Some extra part of a name? Well, right now, yum has a list of packages which are "install-only". We could add a list of packages that are "upgrade-special". When we make the rpm changes, we add a new flag, say "-S" (and the corresponding hooks). Then, any package in the upgrade-special list (which could include a kernel-module-foo mask) would be handled with the rpm -S operation. I'm sure the apt and smart folks would be able to adapt to the new mechanism as well. Then, if it doesn't work, instead of trying to figure out which hack implementation isn't working right, we have one implementation to troubleshoot: the one in rpm. Seth, I'd be very interested in your opinion on this, as it relates to yum. ~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 fedora at leemhuis.info Sun Apr 3 12:21:46 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Apr 2005 14:21:46 +0200 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112503407.15642.52.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050402192456.A748@mail.harddata.com> <1112503407.15642.52.camel@localhost.localdomain> Message-ID: <1112530906.5173.15.camel@notebook.thl.home> Am Samstag, den 02.04.2005, 22:43 -0600 schrieb Tom 'spot' Callaway: > > There is, of course, this problem that during development a module > > source code may have its own version as well but one can possibly > > overload a release part to get around the issue. > > I don't think we care. Bump the release if a newer version of the > module comes out. :) I don't really like this idea. The version of the kernel-module needs to be somewhere because it is of interest sometimes -- especially with the ati and nvidia X-drivers. Example: nvidia driver version 1.0-7174 will only work with 3d-accel when the kernel-module is compiled from the nvidia-1.0-7174 package, not with modules compiled from older ones (e.g. 1.0-7167). This maybe could be solved by a Provides: kernel-module-nvidia-glx-version = 1.0-7174 in the kernel-module-nvidia-flx package and a Requires: kernel-module-nvidia-glx-version = 1.0-7174 in the nvidia-glx package, which contains the graphics driver itself. Okay, something similar could be achieved by a Requires: kernel-module-nvidia-glx = $(uname -r)-release in the driver-package. But tracking which kernel-module release is build from which "source" is rather confusing this way imho (and makes debugging in a case of an error hard). Also in this case the driver package would have to be rebuild on each kernel-update. So it's a no go afaics. -- Thorsten Leemhuis From fedora at camperquake.de Sun Apr 3 12:56:31 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 3 Apr 2005 14:56:31 +0200 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112482561.15642.39.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> Message-ID: <20050403125631.GB24603@ryoko.camperquake.de> On Sat, Apr 02, 2005 at 04:56:01PM -0600, Tom 'spot' Callaway wrote: > I agree. External modules are a given kernel specific. They should > identify which kernel they are for. > > However, this should not be done in %{name}. Version is a more > appropriate place for this. RPM does currently not provide an appropriate place for this information, that's the whole problem. Sticking it in %{name} is the least ugly approach, IMVHO, but still quite ugly. I think we will need a new mechanism for this, with (at least) one new field in the RPM headers. One question: is this problem confined to kernel modules? Or are there other packages out there which may benefit from this? I read in Mike Harris' blog that RH has an internal CVS version of xorg which allows parallel installation of multiple X servers. Would this mechanism be useful there, too? From paul at all-the-johnsons.co.uk Sun Apr 3 15:24:46 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 03 Apr 2005 16:24:46 +0100 Subject: yum problem with extras Message-ID: <1112541886.6360.22.camel@localhost.localdomain> Hi, I've just added the extras repository to my config and I've trying to download the headers. It gets the aalib first header and stops dead. Just hangs there. I aborted that transaction and decided to install Allegro. Again, gets to the end of the first header and stops dead. Is there currently a problem with the downloads.fedora.redhat.com extras repo? TTFN Paul -- "It is often said that something cannot be libel if it is the truth. This has had to be amended to 'something cannot be libel if it is the truth or if the bank balance says otherwise'" - US Today -------------- 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 Sun Apr 3 16:32:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Apr 2005 11:32:08 -0500 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <20050403125631.GB24603@ryoko.camperquake.de> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050403125631.GB24603@ryoko.camperquake.de> Message-ID: <1112545928.15642.87.camel@localhost.localdomain> Two replies, one email. What a deal! On Sun, 2005-04-03 at 14:56 +0200, Ralf Ertzinger wrote: > On Sat, Apr 02, 2005 at 04:56:01PM -0600, Tom 'spot' Callaway wrote: > > > I agree. External modules are a given kernel specific. They should > > identify which kernel they are for. > > > > However, this should not be done in %{name}. Version is a more > > appropriate place for this. > > RPM does currently not provide an appropriate place for this information, > that's the whole problem. Sticking it in %{name} is the least ugly approach, > IMVHO, but still quite ugly. Of the three places we could put it, %{name} is the worst. Just imagine if we have builds for 20 different kernels. And you do "yum search kernel-module-foo". You're going to get 20 unique results. Bugzilla? 20 different entries. CVS? 20 different branches. We should treat name as exactly that, its name, not overload it with qualifiers. > I think we will need a new mechanism for this, with (at least) one new field > in the RPM headers. This is probably too much. Every tool on the planet will break if we change the %{name}-%{version}-%{release} scheme. > One question: is this problem confined to kernel modules? Or are there other > packages out there which may benefit from this? I read in Mike Harris' blog > that RH has an internal CVS version of xorg which allows parallel installation > of multiple X servers. Would this mechanism be useful there, too? It's possible. I'm not familiar with his xorg system, but it would run into the same upgrade issues if he tried to make a change to both variants. On Sun, 2005-04-03 at 14:21 +0200, Thorsten Leemhuis wrote: > I don't really like this idea. The version of the kernel-module needs to > be somewhere because it is of interest sometimes -- especially with the > ati and nvidia X-drivers. Example: nvidia driver version 1.0-7174 will > only work with 3d-accel when the kernel-module is compiled from the > nvidia-1.0-7174 package, not with modules compiled from older ones (e.g. > 1.0-7167). This maybe could be solved by a > Provides: kernel-module-nvidia-glx-version = 1.0-7174 > > in the kernel-module-nvidia-flx package and a > Requires: kernel-module-nvidia-glx-version = 1.0-7174 > > in the nvidia-glx package, which contains the graphics driver itself. > > Okay, something similar could be achieved by a > Requires: kernel-module-nvidia-glx = $(uname -r)-release > in the driver-package. But tracking which kernel-module release is build > from which "source" is rather confusing this way imho (and makes > debugging in a case of an error hard). Also in this case the driver > package would have to be rebuild on each kernel-update. So it's a no go > afaics. OK, I'm not entirely sure how: rpm -q kernel-module-nvidia-glx --provides | grep kernel-module-nvidia-glx-version is all that confusing. :) However, if the consensus is that the version number needs to appear in the n-v-r, we could overload the %{release} field with that information. So: Name: kernel-module-foo Version: 2.6.10_3smp Release: 1.0_7174.1 But, in the driver package, you'd still have to use a: Requires: kernel-module-nvidia-glx-version >= 1.0-7174 And Provides: that field in the kernel-module package. So, here's my handy checklist: - Does the end user care about the module subversion? Probably not. (And if they do, its easy to document how to find it for any kernel-module-*, we can standardize a "kernel-module-%{name}-version" provides as a mandatory spec item.) - Can we track the module subversion using internal provides? Yes. Unlike your statement above, a driver package rebuild would not be required on each kernel-update, since the Requires is a >=. If the driver needs "at least" that version of a module, the >= works. If the driver needs to match the kernel module version exactly, then you need to rebuild on updates that change the kernel module version number, but not for minor fixes such as bugfixes to open source code (that don't consist of upstream version updates). - Then, does the kernel module version need to show up in the n-v-r? I say no. But again, if all the people packaging kernel modules say yes, we can overload the %{release} field. It just won't help your dependency checks. ~spot From fedora at leemhuis.info Sun Apr 3 17:38:39 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Apr 2005 19:38:39 +0200 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112545928.15642.87.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050403125631.GB24603@ryoko.camperquake.de> <1112545928.15642.87.camel@localhost.localdomain> Message-ID: <1112549920.5173.43.camel@notebook.thl.home> Am Sonntag, den 03.04.2005, 11:32 -0500 schrieb Tom 'spot' Callaway: > Two replies, one email. What a deal! I found it a bit confusing ;-) Anyway: > On Sun, 2005-04-03 at 14:21 +0200, Thorsten Leemhuis wrote: > > I don't really like this idea. The version of the kernel-module needs > to > > be somewhere because it is of interest sometimes [...] > OK, I'm not entirely sure how: > rpm -q kernel-module-nvidia-glx --provides | grep kernel-module-nvidia-glx-version > is all that confusing. :) I said it should be somewhere. Somewhere also meant a virtual provides ;-) > However, if the consensus is that the version number needs to appear in the n-v-r, we could > overload the %{release} field with that information. > > So: > Name: kernel-module-foo > Version: 2.6.10_3smp > Release: 1.0_7174.1 I would prefer something like that. (The reason is found below). I'm still unsure if it should be Release: 1.0_7174.1 or Release: 1.1.0_7174 I think i would prefer the later. [...] > So, here's my handy checklist: > > - Does the end user care about the module subversion? Probably not. (And > if they do, its easy to document how to find it for any kernel-module-*, > we can standardize a "kernel-module-%{name}-version" provides as a > mandatory spec item.) If it is in n-v-r it has one major benefit: It is in the bugzilla report *if* the reporter specifies the n-v-r of the component he reports the bug against (as he should) > - Can we track the module subversion using internal provides? Yes. > Unlike your statement above, a driver package rebuild would not be > required on each kernel-update, since the Requires is a >=. If the > driver needs "at least" that version of a module, the >= works. Yes, as long as we have the Provides:kernel-module-nvidia-glx-version (the rebuild would be needed if we would not have it -- maybe that was not entirely clear in my mail; I just wanted you to know about the problem in general) > - Then, does the kernel module version need to show up in the n-v-r? I > say no. I never requested it should be there ;-) But yes, I think it could be "Release" without doing harm. > But again, if all the people packaging kernel modules say yes, we can > overload the %{release} field. Other opinions? Maybe we could make this optional?! > It just won't help your dependency > checks. Yeah, that's right. -- Thorsten Leemhuis From toshio at tiki-lounge.com Sun Apr 3 17:54:34 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 03 Apr 2005 13:54:34 -0400 Subject: Suggestion: quilt In-Reply-To: <1112322062.12105.44.camel@jdub.homelinux.org> References: <1112322062.12105.44.camel@jdub.homelinux.org> Message-ID: <1112550875.5995.15.camel@Madison.badger.com> On Thu, 2005-03-31 at 20:21 -0600, Josh Boyer wrote: > Howdy, > > I built a package for quilt that I think should be up to Extras > standards. I believe I have a sponsor already, but I'm still firming > some things up with my employer before submitting my papers for CVS > access. Here's a patch for your quilt package. Changelog: - Full URL for Source. - Changed some of the entries in the %%files section to own more directories, add more docs, and mark config files as config. - Add some BuildRequires, configure switches and Requires so various quilt commandline options work. I have just started using quilt, so there may be more Requires that need to be added in order to make everything function properly. I ran everything through bash --rpm-requires for good measure so it's as complete as can be without exhaustive testing. -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: quilt.patch Type: text/x-patch Size: 2465 bytes Desc: 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 tcallawa at redhat.com Sun Apr 3 18:11:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Apr 2005 13:11:53 -0500 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112549920.5173.43.camel@notebook.thl.home> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050403125631.GB24603@ryoko.camperquake.de> <1112545928.15642.87.camel@localhost.localdomain> <1112549920.5173.43.camel@notebook.thl.home> Message-ID: <1112551913.15642.95.camel@localhost.localdomain> On Sun, 2005-04-03 at 19:38 +0200, Thorsten Leemhuis wrote: > > However, if the consensus is that the version number needs to appear in the n-v-r, we could > > overload the %{release} field with that information. > > > > So: > > Name: kernel-module-foo > > Version: 2.6.10_3smp > > Release: 1.0_7174.1 > > I would prefer something like that. (The reason is found below). I'm > still unsure if it should be > > Release: 1.0_7174.1 > or > Release: 1.1.0_7174 Seems reasonable. Your bugzilla reasoning makes sense. Does this syntax look good to people? %define modulever 1.0_7174 Release: 1.%{modulever} Provides: %{name}-version = %{modulever} ~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 ville.skytta at iki.fi Sun Apr 3 21:36:22 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 04 Apr 2005 00:36:22 +0300 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112551913.15642.95.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050403125631.GB24603@ryoko.camperquake.de> <1112545928.15642.87.camel@localhost.localdomain> <1112549920.5173.43.camel@notebook.thl.home> <1112551913.15642.95.camel@localhost.localdomain> Message-ID: <1112564182.24368.117.camel@bobcat.mine.nu> On Sun, 2005-04-03 at 13:11 -0500, Tom 'spot' Callaway wrote: > On Sun, 2005-04-03 at 19:38 +0200, Thorsten Leemhuis wrote: > > > Release: 1.0_7174.1 > > or > > Release: 1.1.0_7174 > > Seems reasonable. Your bugzilla reasoning makes sense. > > Does this syntax look good to people? > > %define modulever 1.0_7174 > > Release: 1.%{modulever} This is better than %{modulever}.1 in the sense that if %{modulever} changes in a non-symmetrical or otherwise unexpected way, rpm version comparison can be tuned by bumping the "1" where needed. In fedora.us terms, it's essentially the same as the "vepoch". > Provides: %{name}-version = %{modulever} Not sure what value "-version" has there. What's wrong with just using the usual "Provides: %{name} = %{modulever}"? From jwboyer at jdub.homelinux.org Sun Apr 3 22:07:37 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Apr 2005 17:07:37 -0500 Subject: Suggestion: quilt In-Reply-To: <1112550875.5995.15.camel@Madison.badger.com> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> Message-ID: <1112566058.6160.5.camel@jdub.homelinux.org> On Sun, 2005-04-03 at 13:54 -0400, Toshio wrote: > > Here's a patch for your quilt package. Changelog: > > - Full URL for Source. > - Changed some of the entries in the %%files section to own more > directories, add more docs, and mark config files as config. > - Add some BuildRequires, configure switches and Requires so various > quilt commandline options work. Cool, thx. > > I have just started using quilt, so there may be more Requires that need > to be added in order to make everything function properly. I ran > everything through bash --rpm-requires for good measure so it's as > complete as can be without exhaustive testing. Ok. Applied with a minor whitespace fixup. New packages at: http://jdub.homelinux.org/files/ Hopefully I'll have things sorted out by the end of this coming week so I can get this into CVS. josh From tcallawa at redhat.com Sun Apr 3 22:32:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Apr 2005 17:32:39 -0500 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112564182.24368.117.camel@bobcat.mine.nu> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050403125631.GB24603@ryoko.camperquake.de> <1112545928.15642.87.camel@localhost.localdomain> <1112549920.5173.43.camel@notebook.thl.home> <1112551913.15642.95.camel@localhost.localdomain> <1112564182.24368.117.camel@bobcat.mine.nu> Message-ID: <1112567559.15642.124.camel@localhost.localdomain> On Mon, 2005-04-04 at 00:36 +0300, Ville Skytt? wrote: > > Provides: %{name}-version = %{modulever} > > Not sure what value "-version" has there. What's wrong with just using > the usual "Provides: %{name} = %{modulever}"? I chose a unique string to simplify comparisons. Since we already have: kernel-module-foo = 2.6.10_3smp kernel-module-foo = 2.6.10_3smp-1.%{modulever} Do we also want: kernel-module-foo = %{modulever} I think thats just asking for confusion down the line. :) The unique variable gives us a value with no other possible definition. ~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 Mon Apr 4 03:25:12 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Apr 2005 22:25:12 -0500 Subject: Review: Comical Message-ID: <1112585112.15642.136.camel@localhost.localdomain> Please review this package for FE. I'm willing to submit and maintain it. Description: Comical is a fully featured GUI comic book viewer using wxWindows. It can view CBZ format files. (CBR format files are viewable if unrar is present). URL: http://comical.sourceforge.net/ The package and the spec file can be found here: http://people.redhat.com/tcallawa/comical/ Thanks, ~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 bdpepple at ameritech.net Mon Apr 4 04:17:19 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 04 Apr 2005 00:17:19 -0400 Subject: Review: Comical In-Reply-To: <1112585112.15642.136.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> Message-ID: <1112588239.14394.10.camel@localhost.localdomain> On Sun, 2005-04-03 at 22:25 -0500, Tom 'spot' Callaway wrote: > Please review this package for FE. I'm willing to submit and maintain > it. > > Description: > Comical is a fully featured GUI comic book viewer using wxWindows. It > can view CBZ format files. (CBR format files are viewable if unrar is > present). > > URL: http://comical.sourceforge.net/ > > The package and the spec file can be found here: > http://people.redhat.com/tcallawa/comical/ > The spec looks fine. Though, you might want to add this patch to correct errors if the archives contains images with '[' or ']' in the filename. Back when I looked at it, a bunch of users had problems with crashing while opening archives. /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: comical.patch Type: text/x-patch Size: 2321 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 tcallawa at redhat.com Mon Apr 4 05:01:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Apr 2005 00:01:56 -0500 Subject: Review: Comical In-Reply-To: <1112588239.14394.10.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> Message-ID: <1112590916.15642.137.camel@localhost.localdomain> On Mon, 2005-04-04 at 00:17 -0400, Brian Pepple wrote: > The spec looks fine. Though, you might want to add this patch to > correct errors if the archives contains images with '[' or ']' in the > filename. Back when I looked at it, a bunch of users had problems with > crashing while opening archives. Good catch. Patch applied, files updated: http://people.redhat.com/tcallawa/comical/ ~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 skvidal at phy.duke.edu Mon Apr 4 05:31:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Apr 2005 01:31:25 -0400 Subject: yum problem with extras In-Reply-To: <1112541886.6360.22.camel@localhost.localdomain> References: <1112541886.6360.22.camel@localhost.localdomain> Message-ID: <1112592685.2894.7.camel@cutter> On Sun, 2005-04-03 at 16:24 +0100, Paul wrote: > Hi, > > I've just added the extras repository to my config and I've trying to > download the headers. It gets the aalib first header and stops dead. > Just hangs there. > > I aborted that transaction and decided to install Allegro. Again, gets > to the end of the first header and stops dead. > > Is there currently a problem with the downloads.fedora.redhat.com extras > repo? > okay, I'm confused. you're using yum 2.0.X with fedora extras off of download.fedora.redhat.com? what ver of fedora are you using? what ver of yum are you using? -sv From bdpepple at ameritech.net Mon Apr 4 05:36:41 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 04 Apr 2005 01:36:41 -0400 Subject: Review: Comical In-Reply-To: <1112590916.15642.137.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> Message-ID: <1112593001.17071.4.camel@localhost.localdomain> On Mon, 2005-04-04 at 00:01 -0500, Tom 'spot' Callaway wrote: > Good catch. Patch applied, files updated: > > http://people.redhat.com/tcallawa/comical/ This looks good enough to import into CVS. It might also be nice to add a .desktop file to this package, also. I should have time to review this tomorrow if you would like. /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 adrian at lisas.de Mon Apr 4 06:47:10 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 4 Apr 2005 08:47:10 +0200 Subject: Suggestion: quilt In-Reply-To: <1112550875.5995.15.camel@Madison.badger.com> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> Message-ID: <20050404064710.GA8076@lisas.de> On Sun, Apr 03, 2005 at 01:54:34PM -0400, Toshio wrote: > On Thu, 2005-03-31 at 20:21 -0600, Josh Boyer wrote: > > Howdy, > > > > I built a package for quilt that I think should be up to Extras > > standards. I believe I have a sponsor already, but I'm still firming > > some things up with my employer before submitting my papers for CVS > > access. > > Here's a patch for your quilt package. Changelog: > > - Full URL for Source. > - Changed some of the entries in the %%files section to own more > directories, add more docs, and mark config files as config. How about marking config files also as noreplace? And I really don't think that this package should own /etc/bash_completion.d/ because it is already owned by the bash-completion package. How about using a trigger for the bash-completion stuff like I have seen it in other packages (mpc). > - Add some BuildRequires, configure switches and Requires so various > quilt commandline options work. I would also rather see a package without a dependency on %{_sbindir}/sendmail, is this possible? The Requires can also be shorted: rpm-build requires perl, patch, mktemp coreutiles requires grep, findutils so that at least the Requires on perl, patch, mktemp, grep and findutils could be removed. The %description is a bit unusual for Fedora packages because I haven't seen that the Authors are mentioned in any other description. I have only seen this in suse packages and it looks a bit odd. Adrian From ville.skytta at iki.fi Mon Apr 4 07:17:29 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 04 Apr 2005 10:17:29 +0300 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112482561.15642.39.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> Message-ID: <1112599049.24368.177.camel@bobcat.mine.nu> On Sat, 2005-04-02 at 16:56 -0600, Tom 'spot' Callaway wrote: > As I said before, we can skirt this problem if we overload the %{name} > and put the kernel version there. However, this means that in CVS, we'd > have separate branches for every possible kernel version, bugzilla would > have entries for every possible kernel version. Its bad, and we > shouldn't do it. Bad, yes, but I guess the separate Bugzilla and CVS entries would not be a "must", but rather the current state of affairs in how various scripts work. By the way, an instance of this %{name} abuse is kind of already the kernel, kernel-smp, kernel-xen0, kernel-xenU, etc naming scheme. Not exactly the same, but similar. Anyway, I'm not advocating the version-in-name abuse in module packages, if something better, or equivalent but less ugly is found. > We need to teach rpm to perform the following transaction (ignoring > normal dependency checks): > > - package kernel-module-foo-2.6.10_2-1, kernel-module-foo-2.6.10_2smp-1, > and kernel-module-foo-2.6.10_3-1 are installed (-i will permit this). > - user asks for packages kernel-module-foo-2.6.10_2-2, > kernel-module-foo-2.6.10_2smp-2, and kernel-module-foo-2.6.10_3-2 to be > installed. > - rpm looks for existing packages which match %{name}-%{version} for > each of these pending update packages. > - if found, then compare %{release} with that existing > %{name}-%{version} package > - if %{release} of pending update is greater than existing, then > upgrade ONLY that existing package with same %{name}-%{update} > - else, if %{release} of pending update is same as existing, then > compare epoch > - if epoch of pending update is higher, then upgrade ONLY that > existing package with same %{name}-%{update} > - else, if %{release} of pending update is lower than existing, then > exit with error. > - else, if not found, perform standard -i operation on pending update > package. > > Does that make it more clear? :) Yep, but perhaps also unnecessarily hairy; making it possible to shuffle the weight of E, V, and R in rpm version comparisons does not sound good for one's health (the "compare Release before Epoch" case in the above). Some thinking aloud follows, caveat emptor... Could it be simplified/generalized into let's say "upgrade scopes"? Currently, the only, traditional upgrade scope is a package's N. Other valid scopes could be NE, and NEV. Maybe add A if/where necessary or useful. These scopes would be treated like: - N: like it has always been. Compare EVR of packages with name N to decide whether an upgrade is available etc. - NE: compare VR of all packages having the same NE. - NEV: compare R only of all packages having the same NEV. Not sure if/how this should/would affect versioned Obsoletes, Conflicts, and/or Provides. Anyway, in the above kernel module naming+versioning scheme, setting the upgrade scope of these module packages to NEV would probably produce the wanted results. But I'm not sure if this is the right path. We want to restrict the version comparisons so that only module packages built for a specific kernel get compared for upgradeability, otherwise installed in parallel as if they had different %{name}s. Or more generally, make rpm aware of what the packages are built _for_, instead of coming up with new wicked context-free NEVR comparison schemes. So, what about a "For:" tag. For: foo = bar ...or Requires(parent): or something even better. This would be equivalent to "Requires: foo = bar", except that in addition, rpm and depsolvers could use "foo = bar" to group the "child" packages for the upgrade or install decision. Older rpm and depsolver implementations would just ignore the extra info and treat these as normal Requires. From thomas at apestaart.org Mon Apr 4 09:09:03 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 04 Apr 2005 11:09:03 +0200 Subject: Suggestion: quilt In-Reply-To: <1112322062.12105.44.camel@jdub.homelinux.org> References: <1112322062.12105.44.camel@jdub.homelinux.org> Message-ID: <1112605743.5531.2.camel@otto.amantes> On Thu, 2005-03-31 at 20:21 -0600, Josh Boyer wrote: > Howdy, > > I built a package for quilt that I think should be up to Extras > standards. I believe I have a sponsor already, but I'm still firming > some things up with my employer before submitting my papers for CVS > access. Great ! See if a previous package of me for it (http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora- stable/quilt-0.32-0.fdr.1.3/) contains anything you might have missed. Thanks for doing quilt ! Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I know someday you'll have a beautiful life I know you'll be a star in someone else's sky but why oh why oh why why can't it be mine ? <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Mon Apr 4 09:09:37 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 04 Apr 2005 11:09:37 +0200 Subject: ITP: trac, clearsilver In-Reply-To: <1112289776.31596.87.camel@bobcat.mine.nu> References: <1112289776.31596.87.camel@bobcat.mine.nu> Message-ID: <1112605778.5531.4.camel@otto.amantes> Hey Ville, try http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora- stable/clearsilver-0.9.8-0.fdr.1.3/ http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora- stable/python-trac-0.8-0.fdr.1.3/ Thomas On Thu, 2005-03-31 at 20:22 +0300, Ville Skytt? wrote: > http://www.edgewall.com/trac/ > http://www.clearsilver.net/ > > Anyone working on packaging Trac? I'm interested in trying it out, and > will package it soon(tm) for the purposes of trying it out unless > someone's already working on it. Trac depends on Clearsilver. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> You, the only sense the world has ever made <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Mon Apr 4 09:06:19 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 04 Apr 2005 11:06:19 +0200 Subject: [Kind of OT] Bluefish pre 1.0.1 snapshots In-Reply-To: <1112498594.11144.46.camel@garfield.linux.localdomain> References: <1112498594.11144.46.camel@garfield.linux.localdomain> Message-ID: <1112605579.5531.0.camel@otto.amantes> Hi, On Sat, 2005-04-02 at 19:23 -0800, Jim Hayward wrote: > Hi all, > > I currently working on towards the Bluefish 1.0.1 release (mostly just > bug fixes). As an effort to get more bug testers for these snapshots I > would like to get these packaged for FC3. However I'm currently running > a modified FC3 system that isn't suitable for making packages. I'm > looking for a volunteer to package these snapshots for FC3. A common problem. You can make it easy on yourself by using a tool like mach (http://thomas.apestaart.org/projects/mach) to build the rpm in a clean environment. There is mach version that Seth Vidal is working on that uses yum as the package resolver, so give it a spin :) Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I could change your life If you give me that chance to be your man <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From adrian at lisas.de Mon Apr 4 09:57:18 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 4 Apr 2005 11:57:18 +0200 Subject: Review Needed: autossh, bwm-ng, colortail, htop Message-ID: <20050404095718.GA8597@lisas.de> I would like to import following packages into CVS. http://lisas.de/~adrian/rpm/autossh-1.3-1.src.rpm http://lisas.de/~adrian/rpm/bwm-ng-0.5-3.src.rpm http://lisas.de/~adrian/rpm/colortail-0.3.0-1.src.rpm http://lisas.de/~adrian/rpm/htop-0.5-2.src.rpm All this packages are from Dag and I would like to keep the specfiles as close as possible to Dag's version if possible. Adrian From iago.rubio at hispalinux.es Mon Apr 4 10:46:34 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Mon, 04 Apr 2005 12:46:34 +0200 Subject: Review Needed: autossh, bwm-ng, colortail, htop In-Reply-To: <20050404095718.GA8597@lisas.de> References: <20050404095718.GA8597@lisas.de> Message-ID: <1112611595.9581.3.camel@speedy.iagorubio.net> On Mon, 2005-04-04 at 11:57 +0200, Adrian Reber wrote: > I would like to import following packages into CVS. > > http://lisas.de/~adrian/rpm/autossh-1.3-1.src.rpm > http://lisas.de/~adrian/rpm/bwm-ng-0.5-3.src.rpm > http://lisas.de/~adrian/rpm/colortail-0.3.0-1.src.rpm > http://lisas.de/~adrian/rpm/htop-0.5-2.src.rpm > > All this packages are from Dag and I would like to keep the specfiles as > close as possible to Dag's version if possible. It will depend on how close Dag's spec files are to Fedora's packaging guidelines. -- Iago Rubio From bugs.michael at gmx.net Mon Apr 4 11:00:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Apr 2005 13:00:42 +0200 Subject: Review: Comical In-Reply-To: <1112593001.17071.4.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> Message-ID: <20050404130042.69ad3c65.bugs.michael@gmx.net> On Mon, 04 Apr 2005 01:36:41 -0400, Brian Pepple wrote: > On Mon, 2005-04-04 at 00:01 -0500, Tom 'spot' Callaway wrote: > > Good catch. Patch applied, files updated: > > > > http://people.redhat.com/tcallawa/comical/ > > This looks good enough to import into CVS. It might also be nice to add > a .desktop file to this package, also. I should have time to review > this tomorrow if you would like. > > /B For reference: https://bugzilla.fedora.us/show_bug.cgi?id=1452 From jwboyer at jdub.homelinux.org Mon Apr 4 12:35:27 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 4 Apr 2005 07:35:27 -0500 Subject: Suggestion: quilt In-Reply-To: <20050404064710.GA8076@lisas.de> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> Message-ID: <20050404123527.GA6726@yoda.jdub.homelinux.org> On Mon, Apr 04, 2005 at 08:47:10AM +0200, Adrian Reber wrote: > On Sun, Apr 03, 2005 at 01:54:34PM -0400, Toshio wrote: > > Here's a patch for your quilt package. Changelog: > > > > - Full URL for Source. > > - Changed some of the entries in the %%files section to own more > > directories, add more docs, and mark config files as config. > > How about marking config files also as noreplace? And I really don't > think that this package should own /etc/bash_completion.d/ because it is > already owned by the bash-completion package. > How about using a trigger for the bash-completion stuff like I have seen > it in other packages (mpc). Ok, I'll look into that. You're probably right about the bash_completion.d stuff. > > > - Add some BuildRequires, configure switches and Requires so various > > quilt commandline options work. > > I would also rather see a package without a dependency on > %{_sbindir}/sendmail, is this possible? The mail function of the newest quilt requires this. I don't think it cares which MTA is installed, as long as something is providing sendmail type functionality. > > The Requires can also be shorted: rpm-build requires perl, patch, mktemp > coreutiles requires grep, findutils so that at least the Requires on > perl, patch, mktemp, grep and findutils could be removed. Ok, good point. I look these over and shorten them where I can. > > The %description is a bit unusual for Fedora packages because I haven't > seen that the Authors are mentioned in any other description. I have only seen > this in suse packages and it looks a bit odd. I guess that's not surprising since this is adapted from a SuSE spec file. I can re-write the %description if there are objections to how it is today. I just want to make sure credit is given where it's due. Thanks for reviewing. I'm a bit new to making RPMs, so bear with me :). I appreciate the comments. josh From jwboyer at jdub.homelinux.org Mon Apr 4 12:36:21 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 4 Apr 2005 07:36:21 -0500 Subject: Suggestion: quilt In-Reply-To: <1112605743.5531.2.camel@otto.amantes> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112605743.5531.2.camel@otto.amantes> Message-ID: <20050404123621.GB6726@yoda.jdub.homelinux.org> On Mon, Apr 04, 2005 at 11:09:03AM +0200, Thomas Vander Stichele wrote: > On Thu, 2005-03-31 at 20:21 -0600, Josh Boyer wrote: > > Howdy, > > > > I built a package for quilt that I think should be up to Extras > > standards. I believe I have a sponsor already, but I'm still firming > > some things up with my employer before submitting my papers for CVS > > access. > > Great ! > See if a previous package of me for it > (http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora- > stable/quilt-0.32-0.fdr.1.3/) contains anything you might have missed. > Thanks for doing quilt ! Ok, I'll take a look at it tonight. Thanks :). josh From toshio at tiki-lounge.com Mon Apr 4 13:33:10 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 04 Apr 2005 09:33:10 -0400 Subject: Suggestion: quilt In-Reply-To: <20050404064710.GA8076@lisas.de> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> Message-ID: <1112621591.27345.23.camel@Madison.badger.com> On Mon, 2005-04-04 at 08:47 +0200, Adrian Reber wrote: > On Sun, Apr 03, 2005 at 01:54:34PM -0400, Toshio wrote: > > - Changed some of the entries in the %%files section to own more > > directories, add more docs, and mark config files as config. > > How about marking config files also as noreplace? When should config files be noreplace and when should they not? We can't tell when we build this version of quilt whether a later version will make an incompatible change to the quiltrc config.... > And I really don't > think that this package should own /etc/bash_completion.d/ because it is > already owned by the bash-completion package. Since this package doesn't depend on bash-completion, it has to own the bash_completion.d directory unless... > How about using a trigger for the bash-completion stuff like I have seen > it in other packages (mpc). ...you create a different mechanism to deal with it. I was unaware of the trigger stuff you refer to but it looks almost right:: %triggerin -- bash-completion ln -sf %{_datadir}/%{name}/%{name}-bashrc \ %{_sysconfdir}/bash_completion.d/%{name} %triggerun -- bash-completion [ $2 -gt 0 ] || rm -f %{_sysconfdir}/bash_completion.d/%{name} I don't use triggers much but I think this doesn't handle the case where bash_completion is installed and quilt/mpc gets uninstalled. So it also needs:: %postun [ $1 = 0 ] && rm -f %{_sysconfdir}/bash_completion.d/%{name} For quilt, you'd also want this in %install:: mv ${RPM_BUILD_ROOT}/bash_completion.d/%{name} \ ${RPM_BUILD_ROOT}/%{_datadir}/%{name}/%{name}-bashrc rm -rf ${RPM_BUILD_ROOT}/bash_completion.d > > - Add some BuildRequires, configure switches and Requires so various > > quilt commandline options work. > > I would also rather see a package without a dependency on > %{_sbindir}/sendmail, is this possible? > Not without having errors at runtime.... A runtime check could be patched in and sent upstream, though. > The Requires can also be shorted: rpm-build requires perl, patch, mktemp > coreutiles requires grep, findutils so that at least the Requires on > perl, patch, mktemp, grep and findutils could be removed. > > The %description is a bit unusual for Fedora packages because I haven't > seen that the Authors are mentioned in any other description. I have only seen > this in suse packages and it looks a bit odd. > Good points. -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 symbiont at berlios.de Mon Apr 4 14:29:26 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 4 Apr 2005 22:29:26 +0800 Subject: Pre-Review: Asterisk In-Reply-To: <1112465119.15642.16.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> Message-ID: <200504042229.27227.symbiont@berlios.de> On Sunday 03 April 2005 02:05, Tom 'spot' Callaway wrote: > There are several ways to hack around this issue. We could make each > package have a unique name by cramming the kernel uname -r in the > addon package name, but thats hideous. It breaks all our ownership, > bugzilla, and CVS infrastructure. AFAIK, ATrpms/dag, et al has been doing this successfully for awhile now and it works fairly well. Pushing a native change into RPM might be worth the effort but you're talking FC5 before the fruit of your labors are evident. Then it becomes an issue of laying down the infra for FC4; you'd need a backport into FC4 since it hasn't sunset yet on support at the time. And that means holding out on kernel add-ons until FC5. Seems to me that "ownership, bugzilla, and CVS infrastructure" is an easier problem to tackle. > We could build in a horrible workaround inside yum, but then we'd > need to do the same for every packaging delivery system that people > want to use (yum, apt, smart, etc). yum/smart should focus on macro decisions such as: I upgrade 2.6.11 -> 2.6.11.5 and I want to bring all my kernel add on modules up to date to the latest kernel. Axel brought this up on the smart list and it might be on the roadmap. just my 2 NT, -- -jeff From tcallawa at redhat.com Mon Apr 4 14:35:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Apr 2005 09:35:51 -0500 Subject: Review: Comical In-Reply-To: <20050404130042.69ad3c65.bugs.michael@gmx.net> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> Message-ID: <1112625352.15642.144.camel@localhost.localdomain> On Mon, 2005-04-04 at 13:00 +0200, Michael Schwendt wrote: > For reference: > https://bugzilla.fedora.us/show_bug.cgi?id=1452 Comical doesn't depend on unrar, it just attempts to call unrar to open CBR files. If unrar is there, it works. If not, it doesn't. It can open CBZ (zip and bz2) files just fine. ~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 laroche at redhat.com Mon Apr 4 14:36:35 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 4 Apr 2005 16:36:35 +0200 Subject: Pre-Review: Asterisk In-Reply-To: <200504042229.27227.symbiont@berlios.de> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <200504042229.27227.symbiont@berlios.de> Message-ID: <20050404143635.GA6857@dudweiler.stuttgart.redhat.com> > yum/smart should focus on macro decisions such as: I upgrade 2.6.11 -> > 2.6.11.5 and I want to bring all my kernel add on modules up to date to > the latest kernel. Axel brought this up on the smart list and it might > be on the roadmap. Might make sense to implement some of these decisions only in the tool doing the updates, but without adding changes to the binary format of packages. Additional tag are then easy to set, but at least for testing purposes additonal data can just as well go into additional config files to watch these things working for some time. greetings, Florian La Roche From skvidal at phy.duke.edu Mon Apr 4 14:39:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Apr 2005 10:39:40 -0400 Subject: Pre-Review: Asterisk In-Reply-To: <200504042229.27227.symbiont@berlios.de> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <200504042229.27227.symbiont@berlios.de> Message-ID: <1112625581.2894.34.camel@cutter> > yum/smart should focus on macro decisions such as: I upgrade 2.6.11 -> > 2.6.11.5 and I want to bring all my kernel add on modules up to date to > the latest kernel. Axel brought this up on the smart list and it might > be on the roadmap. Quite frankly, that's not the hard part provided there is some formal structure and definition of their relationships. It's dealing with: an update for a module for kernel 2.6.10 that shows up when the user still has 2.6.10 installed and is in fact, using it, despite that 2.6.11 is out and installed on their system. that's kinda hard and we still need to deal with these properly. -sv From katzj at redhat.com Mon Apr 4 14:45:33 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Apr 2005 10:45:33 -0400 Subject: Suggestion: quilt In-Reply-To: <1112621591.27345.23.camel@Madison.badger.com> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> <1112621591.27345.23.camel@Madison.badger.com> Message-ID: <1112625934.9921.17.camel@bree.local.net> On Mon, 2005-04-04 at 09:33 -0400, Toshio wrote: > On Mon, 2005-04-04 at 08:47 +0200, Adrian Reber wrote: > > How about using a trigger for the bash-completion stuff like I have seen > > it in other packages (mpc). > > ...you create a different mechanism to deal with it. I was unaware of > the trigger stuff you refer to but it looks almost right:: Please don't use a trigger unless they're absolutely, 100% required with no other way around them. Writing a trigger that is completely future proof (which is required, given how triggers work) is *extremely* difficult to do. Jeremy From thm at duke.edu Mon Apr 4 16:06:33 2005 From: thm at duke.edu (Hunter Matthews) Date: Mon, 04 Apr 2005 12:06:33 -0400 Subject: Request for Review: bioperl and its dependancies Message-ID: <1112630793.2789.0.camel@jade.biology.duke.edu> [Attempted to send this friday, didn't see it] bioperl is a popular perl module for bioinformatics work. It has a number of dependancies, some of which are already in FC-3 or FE - the rest are here. All of the following are at http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ perl-bioperl Descrption: Bioperl is a package of public domain Perl tools for computational molecular biology. Its non-FC3/non-FE dependancies are: perl-GD-SVG GD::SVG seamlessly enables the scalable vector graphics (SVG) output from scripts written using GD. It accomplishes this by translating GD functions into SVG functions. perl-Graph This is Graph, a Perl module for dealing with graphs, the abstract data structures. (If you were looking for pie charts, I'm sorry.) perl-Heap This is a collection of routines for managing a heap data structure. There are two major components: a heap component, and an element component. perl-MIME-Lite MIME::Lite is intended as a simple, standalone module for generating (not parsing!) MIME messages... specifically, it allows you to output a simple, decent single- or multi-part message with text or binaryattachments. It does not require that you have the Mail:: or MIME:: modules installed. perl-SOAP-Lite SOAP::Lite for Perl is a collection of Perl modules which provides a simple and lightweight interface to the Simple Object Access Protocol (SOAP) both on client and server side. perl-SVG SVG.pm is a perl extention to generate stand-alone or inline SVG (scaleable vector graphics) images using the W3C SVG xml recommendation. perl-Text-Shellwords This is a thin wrapper around the shellwords.pl package, which comes preinstalled with Perl. This module imports a single subroutine, shellwords(). The shellwords() routine parses lines of text and returns a set of tokens using the same rules that the Unix shell does for its command-line arguments. Tokens are separated by whitespace, and can be delimited by single or double quotes. The module also respects backslash escapes. perl-XML-Writer XML::Writer is a simple Perl module for writing XML documents: it takes care of constructing markup and escaping data correctly, and by default, it also performs a significant amount of well-formedness checking on the output, to make certain (for example) that start and end tags match, that there is exactly one document element, and that there are not duplicate attribute names. Please be a bit gentle with any perlisms - I'm the packager, but am not really a perl expert. -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From nutello at sweetness.com Mon Apr 4 16:50:32 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Mon, 4 Apr 2005 18:50:32 +0200 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <1112630793.2789.0.camel@jade.biology.duke.edu> References: <1112630793.2789.0.camel@jade.biology.duke.edu> Message-ID: <20050404165032.GC2742@plain.rackshack.net> On Mon, Apr 04, 2005 at 12:06:33PM -0400, Hunter Matthews wrote: > Please be a bit gentle with any perlisms - I'm the packager, but am not > really a perl expert. I have a SPEC file for Bioperl that I was working on. The first differences I could spot are BuildRequires: perl-SVG perl-GD-SVG perl-DBD-MySQL perl-IO-stringy (These are needed in order for mach to pull in the dependencies in a clean root) %doc doc examples models scripts %doc AUTHORS BUGS Changes DEPRECATED FAQ INSTALL LICENSE PLATFORMS README bptutorial.pl More as I get a closer look. -- Rudi From thm at duke.edu Mon Apr 4 17:31:06 2005 From: thm at duke.edu (Hunter Matthews) Date: Mon, 04 Apr 2005 13:31:06 -0400 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <20050404165032.GC2742@plain.rackshack.net> References: <1112630793.2789.0.camel@jade.biology.duke.edu> <20050404165032.GC2742@plain.rackshack.net> Message-ID: <1112635865.2789.5.camel@jade.biology.duke.edu> > BuildRequires: perl-SVG perl-GD-SVG perl-DBD-MySQL perl-IO-stringy > Added - We're mostly postgres here, so I added perl-DBD-Pg as well. > (These are needed in order for mach to pull in the dependencies in a > clean root) Yeah, I flubbed that one. > %doc doc examples models scripts > %doc AUTHORS BUGS Changes DEPRECATED FAQ INSTALL LICENSE PLATFORMS README bptutorial.pl > Done. > More as I get a closer look. bioperl*-2 and the new specfile are now included: http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From bugs.michael at gmx.net Mon Apr 4 17:57:16 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Apr 2005 19:57:16 +0200 Subject: Review: Comical In-Reply-To: <1112625352.15642.144.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> Message-ID: <20050404195716.5e2c683f.bugs.michael@gmx.net> On Mon, 04 Apr 2005 09:35:51 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-04 at 13:00 +0200, Michael Schwendt wrote: > > > For reference: > > https://bugzilla.fedora.us/show_bug.cgi?id=1452 > > Comical doesn't depend on unrar, it just attempts to call unrar to open > CBR files. If unrar is there, it works. If not, it doesn't. It can open > CBZ (zip and bz2) files just fine. > > ~spot Consider this message a "veto" then. Rationale and example given in fedora.us bug #1452. Actually, Comical crashes badly when you don't have unrar and try to open a rar compressed comic book. There's no error checking in the code. Get upstream to add a small error dialog, and it will be fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mricon at gmail.com Mon Apr 4 18:02:17 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 4 Apr 2005 14:02:17 -0400 Subject: Review: python-elementtree, python-kid, repoview In-Reply-To: References: Message-ID: On Mar 30, 2005 11:28 AM, Konstantin Ryabitsev wrote: > Hello, all: > > I've successfully imported the following packages into the devel > branch (since I've not heard anything about not importing > python-elementtree there, I've put it with the others, since otherwise > it'd break builds). > > Please review these when you have a chance. I think they should be satisfactory: > > python-elementtree > python-kid > repoview Okay, so is everyone "silently nodding?" :) What are the rules on "no objections have been received within N days?" (N is currently equalling 5). Does that translate into "approved?" Regards. -- Konstantin Ryabitsev Zlotniks, INC From bugs.michael at gmx.net Mon Apr 4 18:06:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Apr 2005 20:06:15 +0200 Subject: Review: Comical In-Reply-To: <20050404195716.5e2c683f.bugs.michael@gmx.net> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> <20050404195716.5e2c683f.bugs.michael@gmx.net> Message-ID: <20050404200615.11ceeb5a.bugs.michael@gmx.net> Btw, Brian's comical package has no problems (with unrar installed) to open his example comic book. Your one fails with an error message in its log file. From nutello at sweetness.com Mon Apr 4 18:23:42 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Mon, 4 Apr 2005 20:23:42 +0200 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <1112635865.2789.5.camel@jade.biology.duke.edu> References: <1112630793.2789.0.camel@jade.biology.duke.edu> <20050404165032.GC2742@plain.rackshack.net> <1112635865.2789.5.camel@jade.biology.duke.edu> Message-ID: <20050404182342.GA25861@plain.rackshack.net> On Mon, Apr 04, 2005 at 01:31:06PM -0400, Hunter Matthews wrote: > bioperl*-2 and the new specfile are now included: > http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ I have SRPMs for most of the dependencies you have filtered out (everything, except srsperl, which is a commercial product, and a couple of CPAN modules I haven't managed to package yet). -- Rudi From g.hollestelle at gmail.com Mon Apr 4 19:13:14 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Mon, 4 Apr 2005 21:13:14 +0200 Subject: Review: python-elementtree, python-kid, repoview In-Reply-To: References: Message-ID: <95da2d290504041213170a489e@mail.gmail.com> On Apr 4, 2005 8:02 PM, Konstantin Ryabitsev wrote: > Okay, so is everyone "silently nodding?" :) What are the rules on "no > objections have been received within N days?" (N is currently > equalling 5). Does that translate into "approved?" I'm wondering about that too, I've submitted cherrypy and cherrytemplate for review on March 24 see https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00911.html Apart from a missing %dir that Michael SchwendtI noticed (thanks for that Michael) I have heared nothing about it, according to my access logs 8 different people downloaded the specs and/or SRPMS but I have only heared from Michael. Greets, Gijs From dag at wieers.com Mon Apr 4 19:19:14 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 4 Apr 2005 21:19:14 +0200 (CEST) Subject: Review Needed: autossh, bwm-ng, colortail, htop In-Reply-To: <1112611595.9581.3.camel@speedy.iagorubio.net> References: <20050404095718.GA8597@lisas.de> <1112611595.9581.3.camel@speedy.iagorubio.net> Message-ID: On Mon, 4 Apr 2005, Iago Rubio wrote: > On Mon, 2005-04-04 at 11:57 +0200, Adrian Reber wrote: > > I would like to import following packages into CVS. > > > > http://lisas.de/~adrian/rpm/autossh-1.3-1.src.rpm > > http://lisas.de/~adrian/rpm/bwm-ng-0.5-3.src.rpm > > http://lisas.de/~adrian/rpm/colortail-0.3.0-1.src.rpm > > http://lisas.de/~adrian/rpm/htop-0.5-2.src.rpm > > > > All this packages are from Dag and I would like to keep the specfiles as > > close as possible to Dag's version if possible. > > It will depend on how close Dag's spec files are to Fedora's packaging > guidelines. Please look at them and then comment. I'm open to improve it where necessary. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From thm at duke.edu Mon Apr 4 19:18:35 2005 From: thm at duke.edu (Hunter Matthews) Date: Mon, 04 Apr 2005 15:18:35 -0400 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <20050404182342.GA25861@plain.rackshack.net> References: <1112630793.2789.0.camel@jade.biology.duke.edu> <20050404165032.GC2742@plain.rackshack.net> <1112635865.2789.5.camel@jade.biology.duke.edu> <20050404182342.GA25861@plain.rackshack.net> Message-ID: <1112642315.2941.0.camel@jade.biology.duke.edu> On Mon, 2005-04-04 at 14:23, Rudi Chiarito wrote: > On Mon, Apr 04, 2005 at 01:31:06PM -0400, Hunter Matthews wrote: > > bioperl*-2 and the new specfile are now included: > > http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ > > I have SRPMs for most of the dependencies you have filtered out > (everything, except srsperl, which is a commercial product, and a > couple of CPAN modules I haven't managed to package yet). Are you going to propose those for FE, or do you want to transfer those to me? -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From ivazquez at ivazquez.net Mon Apr 4 19:39:28 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Apr 2005 15:39:28 -0400 Subject: Review: python-elementtree, python-kid, repoview In-Reply-To: References: Message-ID: <1112643568.12252.20.camel@ignacio.ignacio.lan> On Mon, 2005-04-04 at 14:02 -0400, Konstantin Ryabitsev wrote: > Does that translate into "approved?" Personally I'm extremely hesitant to believe that. It's probably preferable to light a fire under people by sending another message to the list, as you have done. -- 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 Apr 4 19:39:32 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Apr 2005 15:39:32 -0400 Subject: Review: python-elementtree, python-kid, repoview In-Reply-To: References: Message-ID: <1112643572.12252.21.camel@ignacio.ignacio.lan> On Wed, 2005-03-30 at 10:28 -0500, Konstantin Ryabitsev wrote: > python-elementtree ? Is it necessary to unzip %SOURCE1 explicitly or will passing -a 1 to %setup work? ? Why are you using the zip files instead of the tarballs? + URL and sources look good. + Ownership looks good. + Builds as non-root on i386. > python-kid + URL and sources look good. + Ownership looks good. + Builds as non-root on i386 > repoview ? Is sed as a BuildRequires overkill? + URL and sources look good. + Ownership looks good. + Builds as non-root on i386. So just 3 questions here to answer AFAICT. -- 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 Mon Apr 4 19:44:06 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 04 Apr 2005 22:44:06 +0300 Subject: Suggestion: quilt In-Reply-To: <1112621591.27345.23.camel@Madison.badger.com> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> <1112621591.27345.23.camel@Madison.badger.com> Message-ID: <1112643846.24368.205.camel@bobcat.mine.nu> On Mon, 2005-04-04 at 09:33 -0400, Toshio wrote: > On Mon, 2005-04-04 at 08:47 +0200, Adrian Reber wrote: > > On Sun, Apr 03, 2005 at 01:54:34PM -0400, Toshio wrote: > > > - Changed some of the entries in the %%files section to own more > > > directories, add more docs, and mark config files as config. > > > > How about marking config files also as noreplace? > When should config files be noreplace and when should they not? We > can't tell when we build this version of quilt whether a later version > will make an incompatible change to the quiltrc config.... You don't have to. When you do know it, ie. when packaging the next version, you can set them as appropriate. IIRC, it's the %config(foo) from the _new_ package that apply when upgrading, not the old one. Setting noreplace in the initial import might be polite in case someone upgrades from a non-FE package if you assume that the old config will work for your new package version. If you don't think it will, don't set noreplace. > > And I really don't > > think that this package should own /etc/bash_completion.d/ because it is > > already owned by the bash-completion package. > > Since this package doesn't depend on bash-completion, it has to own the > bash_completion.d directory unless... > > > How about using a trigger for the bash-completion stuff like I have seen > > it in other packages (mpc). > > ...you create a different mechanism to deal with it. I was unaware of > the trigger stuff you refer to but it looks almost right:: Owning /etc/bash_completion.d would be much simpler. The only package that really benefits from the supplemental bash_completion.d snippet triggers is bash-completion itself as it cannot guarantee that the utils corresponding to those config snippets are available (and even then, it wouldn't be _that_ big a deal, but I'm leaving the triggers in because they are already there, and have no known problems). When installing quilt, you _do_ know that the required executables will be available, so you can just drop the bash-completion snippet in, and things will work. > I don't use triggers much but I think this doesn't handle the case where > bash_completion is installed and quilt/mpc gets uninstalled. So it also > needs:: > %postun > [ $1 = 0 ] && rm -f %{_sysconfdir}/bash_completion.d/%{name} Marking that as %ghost would eliminate the need for this. But you'd still need to own the bash_completion.d dir (%ghost'd too if you like). From ivazquez at ivazquez.net Mon Apr 4 19:58:31 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Apr 2005 15:58:31 -0400 Subject: Review request: python-cherrypy and python-cherrytemplate In-Reply-To: <95da2d290503240150324a28f9@mail.gmail.com> References: <95da2d2905032307391f772092@mail.gmail.com> <20050323165945.2e2fdd92.bugs.michael@gmx.net> <95da2d290503240150324a28f9@mail.gmail.com> Message-ID: <1112644711.12252.24.camel@ignacio.ignacio.lan> On Thu, 2005-03-24 at 10:50 +0100, Gijs Hollestelle wrote: > Anyone else who is interested in these packages and wants to take a > look at them? A full-fledged review is a bit premature, but I'll sponsor them for import. The pyver definition threw me for a loop when I first looked at it, but it's fine. -- 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 Mon Apr 4 19:58:52 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Apr 2005 15:58:52 -0400 Subject: Review: python-elementtree, python-kid, repoview In-Reply-To: <1112643572.12252.21.camel@ignacio.ignacio.lan> References: <1112643572.12252.21.camel@ignacio.ignacio.lan> Message-ID: <1112644733.9921.48.camel@bree.local.net> On Mon, 2005-04-04 at 15:39 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-03-30 at 10:28 -0500, Konstantin Ryabitsev wrote: > > python-elementtree > > ? Is it necessary to unzip %SOURCE1 explicitly or will passing -a 1 to > %setup work? -a1 to setup will work. And, with the release of yum 2.3.2 today, I pulled this into core (with that slight change). But we'll probably still want to branch and have it for FC3. Jeremy From otaylor at redhat.com Mon Apr 4 20:17:00 2005 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 04 Apr 2005 16:17:00 -0400 Subject: Picking up fontforge/libuninamelist Message-ID: <1112645820.5440.46.camel@huygens> I'm taking over as maintainer of the orphaned fontforge and libuninamelist package. I've cleared this with Marius J?hndal, the previous maintainer. Notes: - I'll update the version of fontforge to the newest release for both fc3 and devel. libuninamelist is pretty static for new releases so doesn't need to be rebuilt. - I'm not aware of anything else that needs doing on the package. There are no bugzilla bug reports. If there are any other issues, put them in bugzilla. - I plan to stick with the current numbering scheme: fontforge-0.0-2.20050310 And so forth, though it's a little weird to me. (I'd probably have gone with 0.0.20050310-1 if starting from scratch on the assumption that the first numbered release will be at least 0.1) 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 mricon at gmail.com Mon Apr 4 20:26:30 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 4 Apr 2005 16:26:30 -0400 Subject: Review: python-elementtree, python-kid, repoview In-Reply-To: <1112643572.12252.21.camel@ignacio.ignacio.lan> References: <1112643572.12252.21.camel@ignacio.ignacio.lan> Message-ID: On Apr 4, 2005 3:39 PM, Ignacio Vazquez-Abrams wrote: > ? Is it necessary to unzip %SOURCE1 explicitly or will passing -a 1 to > %setup work? Yes, it will, I was just unaware of such a flag. Good to know. :) > ? Why are you using the zip files instead of the tarballs? Ah-ha! .tar.gz packages are a new addition -- there were only .zip archives when I originally packaged this version. Changed now. > > repoview > > ? Is sed as a BuildRequires overkill? Well, I need specifically version >= 4, since I am doing an in-place edit. It's probably unnecessary, though, since it's been several years since sed's been on version 4. I'll remove the dependency. Cheers, -- Konstantin Ryabitsev Zlotniks, INC From justin.conover at gmail.com Mon Apr 4 21:09:58 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 4 Apr 2005 16:09:58 -0500 Subject: mach wont build on fc3 or rawhide Message-ID: I pulled mach from cvs on a rawhide box and fc3 and it wont build with the following error: [justin at trinity mach]$ mv mach-0.4.5.tar.bz2 ~/rpmbuild/SOURCES/ [justin at trinity mach]$ rpmbuild -ba mach.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.48739 + umask 022 + cd /home/justin/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + echo ' -------------------------------------------------------------- Update needed. The changes in mach-0.4.6-0.fdr.1.2.src.rpm would be insufficient for FC3. --------------------------------------------------------------' + exit 1 error: Bad exit status from /var/tmp/rpm-tmp.48739 (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.48739 (%prep) Why does it say FC3 when this is a rawhide box? What update is needed? thx, From skvidal at phy.duke.edu Mon Apr 4 21:14:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Apr 2005 17:14:33 -0400 Subject: mach wont build on fc3 or rawhide In-Reply-To: References: Message-ID: <1112649273.6556.17.camel@cutter> > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.48739 (%prep) > > > Why does it say FC3 when this is a rawhide box? What update is needed? > It means mach in fedora extras ain't gonna fly right now. that message was intentionally put there to keep people from building it. -sv From justin.conover at gmail.com Mon Apr 4 21:14:25 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 4 Apr 2005 16:14:25 -0500 Subject: mach wont build on fc3 or rawhide In-Reply-To: <1112649273.6556.17.camel@cutter> References: <1112649273.6556.17.camel@cutter> Message-ID: On Apr 4, 2005 4:14 PM, seth vidal wrote: > > RPM build errors: > > Bad exit status from /var/tmp/rpm-tmp.48739 (%prep) > > > > > > Why does it say FC3 when this is a rawhide box? What update is needed? > > > > It means mach in fedora extras ain't gonna fly right now. > > that message was intentionally put there to keep people from building > it. > > -sv > > Would you advice useing the one from duke? From skvidal at phy.duke.edu Mon Apr 4 21:17:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 04 Apr 2005 17:17:12 -0400 Subject: mach wont build on fc3 or rawhide In-Reply-To: References: <1112649273.6556.17.camel@cutter> Message-ID: <1112649433.6556.19.camel@cutter> > > It means mach in fedora extras ain't gonna fly right now. > > > > that message was intentionally put there to keep people from building > > it. > > > > -sv > > > > > > Would you advice useing the one from duke? you building things for fedora core 3/devel? if so then read this: http://fedoraproject.org/wiki/UsingMach -sv From tcallawa at redhat.com Mon Apr 4 22:33:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Apr 2005 17:33:19 -0500 Subject: Review: Comical In-Reply-To: <20050404195716.5e2c683f.bugs.michael@gmx.net> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> <20050404195716.5e2c683f.bugs.michael@gmx.net> Message-ID: <1112653999.5483.13.camel@localhost.localdomain> On Mon, 2005-04-04 at 19:57 +0200, Michael Schwendt wrote: > Consider this message a "veto" then. Rationale and example given in > fedora.us bug #1452. Actually, Comical crashes badly when you don't have > unrar and try to open a rar compressed comic book. There's no error > checking in the code. Get upstream to add a small error dialog, and it > will be fine. New comical package 0.4-3: - Small error dialog added, along with graceful checking for unrar. (comical no longer crashes when unrar isn't present) - Comical no longer sorts images in archives by default (new sort option allows this if you still want it to do that). - Added desktop entry - Added logo - Added dependencies on bzip2 and unzip All files can be found here: http://people.redhat.com/tcallawa/comical/ ~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 skvidal at fedoraproject.org Mon Apr 4 22:50:19 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 04 Apr 2005 18:50:19 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1112655019.6556.24.camel@cutter> Hi Folks, Sorry for the delay on some builds, I've been busy working on making it so I no longer have to do builds. :) abiword contact-lookup-applet deskbar-applet edb edb-devel edb-gtk edb-ncurses fbida fbida-fbgs fbida-ida fontforge fslint fyre ghasher gnome-blog gnotime gnumeric gnumeric-devel htmltmpl id3-py kphone leafpad libosip libosip-devel libosip2 libosip2-devel linux_logo most pam_mysql perl-MIME-Types putty pybliographer python-bibtex python-crypto python-dialog pyzor repoml revelation sopwith ufraw For any questions about using fedora extras go here: http://fedoraproject.org/wiki/Extras/UsingExtras For any questions about working on fedora extras go here: http://fedoraproject.org/wiki/Extras Thanks! -sv -------------- 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 Apr 4 23:07:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Apr 2005 01:07:00 +0200 Subject: Review: Comical In-Reply-To: <20050404200615.11ceeb5a.bugs.michael@gmx.net> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> <20050404195716.5e2c683f.bugs.michael@gmx.net> <20050404200615.11ceeb5a.bugs.michael@gmx.net> Message-ID: <20050405010700.34e0b1cb.bugs.michael@gmx.net> On Mon, 4 Apr 2005 20:06:15 +0200, Michael Schwendt wrote: > Btw, Brian's comical package has no problems (with unrar installed) > to open his example comic book. Your one fails with an error message > in its log file. comical-0.4-bracket.patch seems to be the culprit. Also, configure option --with-gtk is invalid and not checked. From paul at all-the-johnsons.co.uk Mon Apr 4 23:51:06 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 05 Apr 2005 00:51:06 +0100 Subject: wxPython Message-ID: <1112658666.6360.64.camel@localhost.localdomain> Hi, I'm trying to grab wxPython from the extras-development repo. Am I correct in thinking that the extra-dev repo isn't in sync with rawhide, but is in sync with FC3. TTFN Paul -- "It is often said that something cannot be libel if it is the truth. This has had to be amended to 'something cannot be libel if it is the truth or if the bank balance says otherwise'" - US Today -------------- 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 Tue Apr 5 00:04:00 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Apr 2005 19:04:00 -0500 Subject: Review: Comical In-Reply-To: <20050405010700.34e0b1cb.bugs.michael@gmx.net> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> <20050404195716.5e2c683f.bugs.michael@gmx.net> <20050404200615.11ceeb5a.bugs.michael@gmx.net> <20050405010700.34e0b1cb.bugs.michael@gmx.net> Message-ID: <1112659440.5483.20.camel@localhost.localdomain> On Tue, 2005-04-05 at 01:07 +0200, Michael Schwendt wrote: > On Mon, 4 Apr 2005 20:06:15 +0200, Michael Schwendt wrote: > > > Btw, Brian's comical package has no problems (with unrar installed) > > to open his example comic book. Your one fails with an error message > > in its log file. > > comical-0.4-bracket.patch seems to be the culprit. > > Also, configure option --with-gtk is invalid and not checked. comical-0.4-4 has these changes made. Updated package bits here: http://people.redhat.com/tcallawa/comical/ Brian, do you have a .CBR or .CBZ that won't load without the bracket patch? If so, can you send it to me? I've confirmed that the example comic book loads with comical-0.4-4. ~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 ivazquez at ivazquez.net Tue Apr 5 00:14:50 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Apr 2005 20:14:50 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1112655019.6556.24.camel@cutter> References: <1112655019.6556.24.camel@cutter> Message-ID: <1112660090.22212.9.camel@ignacio.ignacio.lan> I see that python-amara and python-HTMLgen are in the failure list, but I see no logs for them. Someone wanna please throw me a bone? -- 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 toshio at tiki-lounge.com Tue Apr 5 01:47:47 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 04 Apr 2005 21:47:47 -0400 Subject: Request for sponsor: notecase In-Reply-To: <1112270982.8866.54.camel@ignacio.ignacio.lan> References: <1112270982.8866.54.camel@ignacio.ignacio.lan> Message-ID: <1112665668.2645.3.camel@Madison.badger.com> On Thu, 2005-03-31 at 07:09 -0500, Ignacio Vazquez-Abrams wrote: > notecase: A hierarchical note manager > > NoteCase is a hierarchical note manager (aka. outliner). It helps you > organize your everyday text notes into a single document, with > individual notes placed in the tree-like structure (each note can have > its sub-notes, ...). To ensure your privacy, encrypted document format > is supported, along with standard unencrypted format. > > http://notecase.sourceforge.net > http://fedora.ivazquez.net/files/notecase-0.8.2-1.src.rpm I took a look. I'll sponsor the package. I've also got some patches:: one for the spec file, one for the notecase Makefile. -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: notecase-spec.patch Type: text/x-patch Size: 1941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: notecase-strip-unix2dos.patch Type: text/x-patch Size: 919 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 toshio at tiki-lounge.com Tue Apr 5 01:52:36 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 04 Apr 2005 21:52:36 -0400 Subject: ots maintainer Message-ID: <1112665957.2645.9.camel@Madison.badger.com> Hey, who's got the ots package? I've got a bug report with patch to post into Bugzilla but noticed that it doesn't have a Fedora Extras component yet. Unless Caolan is still the maintainer, I'd like to make sure Bugzilla assigns and notifies the right person. -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 ivazquez at ivazquez.net Tue Apr 5 02:40:31 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Apr 2005 22:40:31 -0400 Subject: Request for sponsor: notecase In-Reply-To: <1112665668.2645.3.camel@Madison.badger.com> References: <1112270982.8866.54.camel@ignacio.ignacio.lan> <1112665668.2645.3.camel@Madison.badger.com> Message-ID: <1112668831.22212.11.camel@ignacio.ignacio.lan> On Mon, 2005-04-04 at 21:47 -0400, Toshio wrote: > I've also got some patches:: one for the spec file, one for the notecase > Makefile. Cool. Hit me. -- 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 toshio at tiki-lounge.com Tue Apr 5 02:51:03 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 04 Apr 2005 22:51:03 -0400 Subject: Request for sponsor: notecase In-Reply-To: <1112668831.22212.11.camel@ignacio.ignacio.lan> References: <1112270982.8866.54.camel@ignacio.ignacio.lan> <1112665668.2645.3.camel@Madison.badger.com> <1112668831.22212.11.camel@ignacio.ignacio.lan> Message-ID: <1112669464.3140.13.camel@Madison.badger.com> On Mon, 2005-04-04 at 22:40 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-04-04 at 21:47 -0400, Toshio wrote: > > I've also got some patches:: one for the spec file, one for the notecase > > Makefile. > > Cool. Hit me. They should have been attached to the last message. Here they are again. -Toshio (And in case they're getting stripped out, I threw them onto:: http://www.tiki-lounge.com/~toshio/fedora/notecase-spec.patch http://www.tiki-lounge.com/~toshio/fedora/notecase-strip-unix2dos.patch ) -- ________S_________U_________B_________L_________I_________M_________E________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: notecase-spec.patch Type: text/x-patch Size: 1941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: notecase-strip-unix2dos.patch Type: text/x-patch Size: 919 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 ivazquez at ivazquez.net Tue Apr 5 02:55:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 04 Apr 2005 22:55:18 -0400 Subject: Request for sponsor: notecase In-Reply-To: <1112669464.3140.13.camel@Madison.badger.com> References: <1112270982.8866.54.camel@ignacio.ignacio.lan> <1112665668.2645.3.camel@Madison.badger.com> <1112668831.22212.11.camel@ignacio.ignacio.lan> <1112669464.3140.13.camel@Madison.badger.com> Message-ID: <1112669718.22212.13.camel@ignacio.ignacio.lan> On Mon, 2005-04-04 at 22:51 -0400, Toshio wrote: > They should have been attached to the last message. D'oh! Sorry, Evo is fairly subtle about attachments. Or maybe I'm just tired. -- 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 a.kurtz at hardsun.net Tue Apr 5 03:54:40 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Mon, 04 Apr 2005 20:54:40 -0700 Subject: wxPython In-Reply-To: <1112658666.6360.64.camel@localhost.localdomain> References: <1112658666.6360.64.camel@localhost.localdomain> Message-ID: <1112673280.3613.7.camel@rydia.hardsun.net> On Tue, 2005-04-05 at 00:51 +0100, Paul wrote: > Hi, > > I'm trying to grab wxPython from the extras-development repo. > > Am I correct in thinking that the extra-dev repo isn't in sync with > rawhide, but is in sync with FC3. You are incorrect. The extras-development repo is for test releases/rawhide, as should be apparent from its packages being built against python-2.4 as opposed to FC3's python-2.3. Some packages may not yet have been rebuilt against rawhide (fslint for example) but the intent is there. -- Aaron Kurtz GPG Key ID: ED588CF2 -------------- 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 bdpepple at ameritech.net Tue Apr 5 05:10:02 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 05 Apr 2005 01:10:02 -0400 Subject: Review: Comical In-Reply-To: <1112659440.5483.20.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> <20050404195716.5e2c683f.bugs.michael@gmx.net> <20050404200615.11ceeb5a.bugs.michael@gmx.net> <20050405010700.34e0b1cb.bugs.michael@gmx.net> <1112659440.5483.20.camel@localhost.localdomain> Message-ID: <1112677802.554.10.camel@localhost.localdomain> On Mon, 2005-04-04 at 19:04 -0500, Tom 'spot' Callaway wrote: > Brian, do you have a .CBR or .CBZ that won't load without the bracket > patch? If so, can you send it to me? > > I've confirmed that the example comic book loads with comical-0.4-4. I tested this on a couple of examples, and your version works fine without that bracket patch. I ran into this problem in December on a couple of files, and also saw it mentioned on the message board ( http://www.sketchyorigins.com/comics/showthread.php?t=7932 ), though now I can't reproduce it. So, you should probably drop the patch, since it's definitely causing problems with open archives as Michael mentioned. /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 skvidal at phy.duke.edu Tue Apr 5 05:15:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 01:15:11 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1112660090.22212.9.camel@ignacio.ignacio.lan> References: <1112655019.6556.24.camel@cutter> <1112660090.22212.9.camel@ignacio.ignacio.lan> Message-ID: <1112678111.6556.42.camel@cutter> On Mon, 2005-04-04 at 20:14 -0400, Ignacio Vazquez-Abrams wrote: > I see that python-amara and python-HTMLgen are in the failure list, but > I see no logs for them. Someone wanna please throw me a bone? Hey, I'll add it to the to-be-rebuilt list now, see what's up. -sv From adrian at lisas.de Tue Apr 5 06:04:10 2005 From: adrian at lisas.de (Adrian Reber) Date: Tue, 5 Apr 2005 08:04:10 +0200 Subject: Fedora Extras Development Package Report In-Reply-To: <1112655019.6556.24.camel@cutter> References: <1112655019.6556.24.camel@cutter> Message-ID: <20050405060410.GA5386@lisas.de> According to http://fedoraproject.org/wiki/Extras/FC4Status there has been a build error with cvsup. But after looking at http://fedoraproject.org/extras/development/build-logs/i386/cvsup-16.1-8.h.rpm.log I cannot see any errors and I cannot find a build-log for x86_64. Adrian From adrian at lisas.de Tue Apr 5 06:55:41 2005 From: adrian at lisas.de (Adrian Reber) Date: Tue, 5 Apr 2005 08:55:41 +0200 Subject: Review Needed: autossh, bwm-ng, colortail, htop In-Reply-To: <1112611595.9581.3.camel@speedy.iagorubio.net> References: <20050404095718.GA8597@lisas.de> <1112611595.9581.3.camel@speedy.iagorubio.net> Message-ID: <20050405065541.GA17743@lisas.de> On Mon, Apr 04, 2005 at 12:46:34PM +0200, Iago Rubio wrote: > On Mon, 2005-04-04 at 11:57 +0200, Adrian Reber wrote: > > I would like to import following packages into CVS. > > > > http://lisas.de/~adrian/rpm/autossh-1.3-1.src.rpm > > http://lisas.de/~adrian/rpm/bwm-ng-0.5-3.src.rpm > > http://lisas.de/~adrian/rpm/colortail-0.3.0-1.src.rpm > > http://lisas.de/~adrian/rpm/htop-0.5-2.src.rpm > > > > All this packages are from Dag and I would like to keep the specfiles as > > close as possible to Dag's version if possible. > > It will depend on how close Dag's spec files are to Fedora's packaging > guidelines. I would say the specs are pretty close to the guidelines. I have extracted the specs for easier reviews: http://lisas.de/~adrian/rpm/autossh.spec http://lisas.de/~adrian/rpm/bwm-ng.spec http://lisas.de/~adrian/rpm/colortail.spec http://lisas.de/~adrian/rpm/htop.spec Adrian From skvidal at phy.duke.edu Tue Apr 5 06:59:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 02:59:36 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <20050405060410.GA5386@lisas.de> References: <1112655019.6556.24.camel@cutter> <20050405060410.GA5386@lisas.de> Message-ID: <1112684376.6556.60.camel@cutter> On Tue, 2005-04-05 at 08:04 +0200, Adrian Reber wrote: > According to http://fedoraproject.org/wiki/Extras/FC4Status > there has been a build error with cvsup. But after looking at > http://fedoraproject.org/extras/development/build-logs/i386/cvsup-16.1-8.h.rpm.log > I cannot see any errors and I cannot find a build-log for x86_64. > ahh, it's exclusivearch'd to i386, ppc. I must have messed that one up, I'll push cvsup for i386. sorry. -sv From ivazquez at ivazquez.net Tue Apr 5 07:01:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 03:01:14 -0400 Subject: Request for sponsor: notecase In-Reply-To: <1112665668.2645.3.camel@Madison.badger.com> References: <1112270982.8866.54.camel@ignacio.ignacio.lan> <1112665668.2645.3.camel@Madison.badger.com> Message-ID: <1112684474.22212.17.camel@ignacio.ignacio.lan> On Mon, 2005-04-04 at 21:47 -0400, Toshio wrote: > I've also got some patches:: one for the spec file, one for the notecase > Makefile. I didn't see the perms problem so I left that bit 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 adrian at lisas.de Tue Apr 5 07:06:16 2005 From: adrian at lisas.de (Adrian Reber) Date: Tue, 5 Apr 2005 09:06:16 +0200 Subject: Fedora Extras Development Package Report In-Reply-To: <1112684376.6556.60.camel@cutter> References: <1112655019.6556.24.camel@cutter> <20050405060410.GA5386@lisas.de> <1112684376.6556.60.camel@cutter> Message-ID: <20050405070616.GB18993@lisas.de> On Tue, Apr 05, 2005 at 02:59:36AM -0400, seth vidal wrote: > On Tue, 2005-04-05 at 08:04 +0200, Adrian Reber wrote: > > According to http://fedoraproject.org/wiki/Extras/FC4Status > > there has been a build error with cvsup. But after looking at > > http://fedoraproject.org/extras/development/build-logs/i386/cvsup-16.1-8.h.rpm.log > > I cannot see any errors and I cannot find a build-log for x86_64. > > > > ahh, it's exclusivearch'd to i386, ppc. I must have messed that one up, > I'll push cvsup for i386. Thanks. Adrian From skvidal at fedoraproject.org Tue Apr 5 07:29:22 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 05 Apr 2005 03:29:22 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1112686162.6556.70.camel@cutter> hi all, Built: cvsup-16.1-8.h dbh-1.0.22-3.fc4 gtk-xfce-engine-2.2.6-3.fc4 hamlib-1.2.3-9 ktrack-0.3.0-9.rc1.fc4 libxfce4mcs-4.2.1-3.fc4 libxfce4util-4.2.1-3.fc4 libxfcegui4-4.2.1-4.fc4 logjam-4.4.1-5 xfce-mcs-manager-4.2.1-3.fc4 xfce-mcs-plugins-4.2.1-4.fc4 xfce-utils-4.2.1-3.fc4 xfce4-appfinder-4.2.1-3.fc4 xfce4-icon-theme-4.2.1-5.fc4 xfce4-iconbox-4.2.1-3.fc4 xfce4-panel-4.2.1.1-4.fc4 xfce4-systray-4.2.1-4.fc4 xfce4-toys-4.2.1-4.fc4 xfce4-trigger-launcher-4.2.1-4.fc4 xfdesktop-4.2.1-3.fc4 xffm-4.2.1-5.fc4 xfprint-4.2.1-3.fc4 Problems: python-amara, python-HTMLgen - sorta buildsystem, sorta not - posted to fedora-maintainers about it. -sv -------------- 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 caolanm at redhat.com Tue Apr 5 09:45:52 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 05 Apr 2005 09:45:52 +0000 Subject: ots maintainer In-Reply-To: <1112665957.2645.9.camel@Madison.badger.com> References: <1112665957.2645.9.camel@Madison.badger.com> Message-ID: <1112694352.9670.0.camel@sheol.homelinux.org> On Mon, 2005-04-04 at 21:52 -0400, Toshio wrote: > Hey, who's got the ots package? I've got a bug report with patch to > post into Bugzilla but noticed that it doesn't have a Fedora Extras > component yet. Unless Caolan is still the maintainer, I'd like to make > sure Bugzilla assigns and notifies the right person. Log it anyway and I'll take care of it. C. From skvidal at fedoraproject.org Tue Apr 5 08:36:42 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 05 Apr 2005 04:36:42 -0400 Subject: Fedora Extras 3 Package Report Message-ID: <1112690202.6556.92.camel@cutter> Hi folks, built: ktrack (i386, x86_64) pybliographer (noarch) vpnc (i386, x86_64) tetex-xcolor (i386, x86_64) perl-ExtUtils-ParseXS (i386, x86_64) perl-Test-Manifest (i386, x86_64) fslint (i386, x86_64) easytag (i386, x86_64) xlockmore (i386, x86_64) kphone (i386, x86_64) fyre (i386, x86_64) contact-lookup-applet (i386, x86_64) perl-MIME-Types (i386, x86_64) lablgl (i386, x86_64) - rebuild for ocaml 3.08.3 graveman (i386, x86_64) synce (i386) perl-IO-Zlib (i386, x86_64) fontforge (i386, x86_64) TeXmacs (i386, x86_64) pam_mysql (i386, x86_64) tetex-bytefield (i386, x86_64) synce (i386) errors: alsa-tools - error srpm making - missing patch python-reportlab - x86_64 errors thanks, -sv -------------- 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 all-the-johnsons.co.uk Tue Apr 5 09:42:30 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 05 Apr 2005 10:42:30 +0100 Subject: wxPython In-Reply-To: <1112673280.3613.7.camel@rydia.hardsun.net> References: <1112658666.6360.64.camel@localhost.localdomain> <1112673280.3613.7.camel@rydia.hardsun.net> Message-ID: <1112694150.6360.68.camel@localhost.localdomain> Hi, > > Am I correct in thinking that the extra-dev repo isn't in sync with > > rawhide, but is in sync with FC3. > > You are incorrect. The extras-development repo is for test > releases/rawhide, as should be apparent from its packages being built > against python-2.4 as opposed to FC3's python-2.3. Some packages may not > yet have been rebuilt against rawhide (fslint for example) but the > intent is there. Thanks. wxPython needs rebuilding against python-2.4. TTFN Paul -- "It is often said that something cannot be libel if it is the truth. This has had to be amended to 'something cannot be libel if it is the truth or if the bank balance says otherwise'" - US Today -------------- 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 Apr 5 10:19:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Apr 2005 12:19:46 +0200 Subject: Review: Comical In-Reply-To: <1112659440.5483.20.camel@localhost.localdomain> References: <1112585112.15642.136.camel@localhost.localdomain> <1112588239.14394.10.camel@localhost.localdomain> <1112590916.15642.137.camel@localhost.localdomain> <1112593001.17071.4.camel@localhost.localdomain> <20050404130042.69ad3c65.bugs.michael@gmx.net> <1112625352.15642.144.camel@localhost.localdomain> <20050404195716.5e2c683f.bugs.michael@gmx.net> <20050404200615.11ceeb5a.bugs.michael@gmx.net> <20050405010700.34e0b1cb.bugs.michael@gmx.net> <1112659440.5483.20.camel@localhost.localdomain> Message-ID: <20050405121946.4b130d8f.bugs.michael@gmx.net> On Mon, 04 Apr 2005 19:04:00 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-04-05 at 01:07 +0200, Michael Schwendt wrote: > > On Mon, 4 Apr 2005 20:06:15 +0200, Michael Schwendt wrote: > > > > > Btw, Brian's comical package has no problems (with unrar installed) > > > to open his example comic book. Your one fails with an error message > > > in its log file. > > > > comical-0.4-bracket.patch seems to be the culprit. > > > > Also, configure option --with-gtk is invalid and not checked. > > comical-0.4-4 has these changes made. > > Updated package bits here: > http://people.redhat.com/tcallawa/comical/ > > Brian, do you have a .CBR or .CBZ that won't load without the bracket > patch? If so, can you send it to me? > > I've confirmed that the example comic book loads with comical-0.4-4. > > ~spot 0.4-4 fixes the major issues and is good to go. The explicit and redundant dependency on wxGTK2 could be removed after import. From kaboom at oobleck.net Tue Apr 5 14:51:13 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 5 Apr 2005 10:51:13 -0400 (EDT) Subject: Removed packages In-Reply-To: <1112712683.20867.6.camel@cutter> References: <200504051136.j35Ba5rc024807@porkchop.devel.redhat.com> <604aa791050405073344970889@mail.gmail.com> <1112712683.20867.6.camel@cutter> Message-ID: On Tue, 5 Apr 2005, seth vidal wrote: > they were intentional: > > cyrus-imapd - duplicate imap server > x3270 - oh cmon, this can't be in extras, trivially? Is someone doing these for Extras? I have need for both, so I'm willing to if they're not already covered.... later, chris From thm at duke.edu Tue Apr 5 14:53:24 2005 From: thm at duke.edu (Hunter Matthews) Date: Tue, 05 Apr 2005 10:53:24 -0400 Subject: Request for sponsor: bioperl and its dependencies In-Reply-To: <1112635865.2789.5.camel@jade.biology.duke.edu> References: <1112630793.2789.0.camel@jade.biology.duke.edu> <20050404165032.GC2742@plain.rackshack.net> <1112635865.2789.5.camel@jade.biology.duke.edu> Message-ID: <1112712804.2818.5.camel@jade.biology.duke.edu> On Mon, 2005-04-04 at 13:31, Hunter Matthews wrote: > bioperl*-2 and the new specfile are now included: > http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ I've applied the patches/suggestions supplied on list - is anyone willing to sponsor these packages? -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From skvidal at phy.duke.edu Tue Apr 5 14:54:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 10:54:37 -0400 Subject: Removed packages In-Reply-To: References: <200504051136.j35Ba5rc024807@porkchop.devel.redhat.com> <604aa791050405073344970889@mail.gmail.com> <1112712683.20867.6.camel@cutter> Message-ID: <1112712877.20867.8.camel@cutter> On Tue, 2005-04-05 at 10:51 -0400, Chris Ricker wrote: > On Tue, 5 Apr 2005, seth vidal wrote: > > > they were intentional: > > > > cyrus-imapd - duplicate imap server > > x3270 - oh cmon, this can't be in extras, trivially? > > Is someone doing these for Extras? I have need for both, so I'm willing to > if they're not already covered.... > They're not covered so far. sounds like you should grab the srpms, clean'em up, if they need it and get to submitting your CLA. -sv From toshio at tiki-lounge.com Tue Apr 5 15:06:37 2005 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 05 Apr 2005 11:06:37 -0400 Subject: Request for sponsor: notecase In-Reply-To: <1112684474.22212.17.camel@ignacio.ignacio.lan> References: <1112270982.8866.54.camel@ignacio.ignacio.lan> <1112665668.2645.3.camel@Madison.badger.com> <1112684474.22212.17.camel@ignacio.ignacio.lan> Message-ID: <1112713598.8895.7.camel@Madison.badger.com> On Tue, 2005-04-05 at 03:01 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-04-04 at 21:47 -0400, Toshio wrote: > > I've also got some patches:: one for the spec file, one for the notecase > > Makefile. > > I didn't see the perms problem so I left that bit out. > Hmm.. it looks like the problem is only showing up when I build in mach (old version; I haven't updated my build scripts in quite a while.) In mach, dos2unix is making the files it operates on 0600. Not sure which behaviour the new buildsys would show; the permissions portion would fix things if it's the same as this older version of mach. -Toshio -- _______________ Life is about Loose Ends that never End __________________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 jeff at ocjtech.us Tue Apr 5 18:04:41 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 05 Apr 2005 13:04:41 -0500 Subject: Rebuild audacity Message-ID: <1112724281.4177.8.camel@lt16586.campus.dmacc.edu> Can someone rebuild audacity on extras-development? It needs to be rebuilt to pick up the new flac dependencies. Jeff Ollie -------------- 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 Tue Apr 5 18:09:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 14:09:50 -0400 Subject: Rebuild audacity In-Reply-To: <1112724281.4177.8.camel@lt16586.campus.dmacc.edu> References: <1112724281.4177.8.camel@lt16586.campus.dmacc.edu> Message-ID: <1112724590.20867.61.camel@cutter> On Tue, 2005-04-05 at 13:04 -0500, Jeffrey C. Ollie wrote: > Can someone rebuild audacity on extras-development? It needs to be > rebuilt to pick up the new flac dependencies. > email the maintainer or file a bug and request it. -sv From fedora at camperquake.de Tue Apr 5 19:21:32 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Apr 2005 21:21:32 +0200 Subject: Request for Review: enemies-of-carlotta Message-ID: <20050405212132.34f32e43@nausicaa.camperquake.de> Hi. Just so I do not get out of shape: may someone review http://ryoko.camperquake.de/fedora/enemies-of-carlotta-1.0.3-1.src.rpm ? Please do not import it yet, I'd like to try that myself :) Thanks. -- screen so pure and blue this computer is at peace control alt delete From mricon at gmail.com Tue Apr 5 19:48:03 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 5 Apr 2005 15:48:03 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050405212132.34f32e43@nausicaa.camperquake.de> References: <20050405212132.34f32e43@nausicaa.camperquake.de> Message-ID: On Apr 5, 2005 3:21 PM, Ralf Ertzinger wrote: > Hi. > > Just so I do not get out of shape: may someone review > http://ryoko.camperquake.de/fedora/enemies-of-carlotta-1.0.3-1.src.rpm ? Not related to the .src.rpm per se, but... >From the manpage: --cleaning-woman Deal with bouncing addresses and do other cleanup. You must run enemies-of-carlotta --cleaning-woman periodically. It will clean up all your lists. That's classy right there. Is there a --get-back-to-the-kitchen-and-cook-me-dinner-you-ignorant-slut option? Can this blatant sexism be patched out? Regards, -- Konstantin Ryabitsev Zlotniks, INC From fedora at camperquake.de Tue Apr 5 19:53:01 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Apr 2005 21:53:01 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: References: <20050405212132.34f32e43@nausicaa.camperquake.de> Message-ID: <20050405215301.3bfea4bc@nausicaa.camperquake.de> Moin. Konstantin Ryabitsev wrote: > That's classy right there. Is there a > --get-back-to-the-kitchen-and-cook-me-dinner-you-ignorant-slut option? > > Can this blatant sexism be patched out? Well, this is a little tricky. The name "enemies-of-carlotta" comes from a movie called "Dead men don't wear plaid", and the term "cleaning woman" plays a non-trivial role in it, too. It is a play on words, and quite funny, if you know the movie. From mricon at gmail.com Tue Apr 5 20:11:09 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 5 Apr 2005 16:11:09 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050405215301.3bfea4bc@nausicaa.camperquake.de> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> Message-ID: On Apr 5, 2005 3:53 PM, Ralf Ertzinger wrote: > > Can this blatant sexism be patched out? > > Well, this is a little tricky. The name "enemies-of-carlotta" comes from > a movie called "Dead men don't wear plaid", and the term "cleaning woman" > plays a non-trivial role in it, too. > It is a play on words, and quite funny, if you know the movie. Well... I clearly don't, since I found that mildly offensive. I'm sure, though, that the benefits of not having potentially embarrassing software in Extras would outweigh having an obscure reference that most people wouldn't get. Regards, -- Konstantin Ryabitsev Zlotniks, INC From ivazquez at ivazquez.net Tue Apr 5 20:11:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 16:11:44 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050405212132.34f32e43@nausicaa.camperquake.de> References: <20050405212132.34f32e43@nausicaa.camperquake.de> Message-ID: <1112731904.22212.83.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 21:21 +0200, Ralf Ertzinger wrote: > Just so I do not get out of shape: may someone review > http://ryoko.camperquake.de/fedora/enemies-of-carlotta-1.0.3-1.src.rpm ? %SOURCE0 uses macros. -- 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 Apr 5 20:27:40 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Apr 2005 22:27:40 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> Message-ID: <20050405222740.238eb5c2@nausicaa.camperquake.de> Hi. Konstantin Ryabitsev wrote: > Well... I clearly don't, since I found that mildly offensive. I'm > sure, though, that the benefits of not having potentially embarrassing > software in Extras would outweigh having an obscure reference that > most people wouldn't get. Any other thoughts on this? Do we check and modify software (and break expected behaviour) in order to pass political correctness tests? -- /P{def}def/E{curveto}P/N{moveto}P/G{lineto}P/U{setgray}P/I{fill}P/n {stroke}P (2V<;;F>H>forall N G G I 0 U N E E E E E I 1 U N E E E gsave I grestore 0 U n .3 U N E E n 1 0 360 arc I showpage% auj From fedora at camperquake.de Tue Apr 5 20:31:29 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Apr 2005 22:31:29 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <1112731904.22212.83.camel@ignacio.ignacio.lan> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <1112731904.22212.83.camel@ignacio.ignacio.lan> Message-ID: <20050405223129.4dce5f4f@nausicaa.camperquake.de> Hi. Ignacio Vazquez-Abrams wrote: > %SOURCE0 uses macros. Fixed in http://ryoko.camperquake.de/fedora/enemies-of-carlotta-1.0.3-2.src.rpm -- An iguana can stay under water for 28 minutes. From rdieter at math.unl.edu Tue Apr 5 20:35:44 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Apr 2005 15:35:44 -0500 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050405222740.238eb5c2@nausicaa.camperquake.de> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> <20050405222740.238eb5c2@nausicaa.camperquake.de> Message-ID: <4252F6A0.4030104@math.unl.edu> Ralf Ertzinger wrote: > Konstantin Ryabitsev wrote: >>Well... I clearly don't, since I found that mildly offensive. I'm >>sure, though, that the benefits of not having potentially embarrassing >>software in Extras would outweigh having an obscure reference that >>most people wouldn't get. > Any other thoughts on this? Do we check and modify software (and break > expected behaviour) in order to pass political correctness tests? IMO, certainly not. If anyone doesn't-like/is-offended-by politically-incorrect software "foo" in Extras, they have the right to not use it and/or take their issues upstream. -- Rex From mricon at gmail.com Tue Apr 5 20:39:45 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 5 Apr 2005 16:39:45 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <4252F6A0.4030104@math.unl.edu> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> <20050405222740.238eb5c2@nausicaa.camperquake.de> <4252F6A0.4030104@math.unl.edu> Message-ID: On Apr 5, 2005 4:35 PM, Rex Dieter wrote: > > Any other thoughts on this? Do we check and modify software (and break > > expected behaviour) in order to pass political correctness tests? > > IMO, certainly not. If anyone doesn't-like/is-offended-by > politically-incorrect software "foo" in Extras, they have the right to > not use it and/or take their issues upstream. I will note that software has been previously purged from RH distributions for being "incorrect" (e.g. "bitchx"). I don't really care, but I thought it was worth bringing up for discussion. -- Konstantin Ryabitsev Zlotniks, INC From rdieter at math.unl.edu Tue Apr 5 20:41:26 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Apr 2005 15:41:26 -0500 Subject: Request for Review: enemies-of-carlotta In-Reply-To: References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> <20050405222740.238eb5c2@nausicaa.camperquake.de> <4252F6A0.4030104@math.unl.edu> Message-ID: <4252F7F6.1070908@math.unl.edu> Konstantin Ryabitsev wrote: > On Apr 5, 2005 4:35 PM, Rex Dieter wrote: > >>>Any other thoughts on this? Do we check and modify software (and break >>>expected behaviour) in order to pass political correctness tests? >> >>IMO, certainly not. If anyone doesn't-like/is-offended-by >>politically-incorrect software "foo" in Extras, they have the right to >>not use it and/or take their issues upstream. > I will note that software has been previously purged from RH > distributions for being "incorrect" (e.g. "bitchx"). We're not talking about a commerical RedHat distribution, nor even Fedora Core here, but Extras. -- Rex From mricon at gmail.com Tue Apr 5 20:46:57 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 5 Apr 2005 16:46:57 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <4252F7F6.1070908@math.unl.edu> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> <20050405222740.238eb5c2@nausicaa.camperquake.de> <4252F6A0.4030104@math.unl.edu> <4252F7F6.1070908@math.unl.edu> Message-ID: On Apr 5, 2005 4:41 PM, Rex Dieter wrote: > We're not talking about a commerical RedHat distribution, nor even > Fedora Core here, but Extras. Fine, I withdraw my objection. Keep the --cleaning-woman. Regards, -- Konstantin Ryabitsev Zlotniks, INC From skvidal at phy.duke.edu Tue Apr 5 20:49:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 16:49:07 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <4252F7F6.1070908@math.unl.edu> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <20050405215301.3bfea4bc@nausicaa.camperquake.de> <20050405222740.238eb5c2@nausicaa.camperquake.de> <4252F6A0.4030104@math.unl.edu> <4252F7F6.1070908@math.unl.edu> Message-ID: <1112734147.20867.121.camel@cutter> On Tue, 2005-04-05 at 15:41 -0500, Rex Dieter wrote: > Konstantin Ryabitsev wrote: > > On Apr 5, 2005 4:35 PM, Rex Dieter wrote: > > > >>>Any other thoughts on this? Do we check and modify software (and break > >>>expected behaviour) in order to pass political correctness tests? > >> > >>IMO, certainly not. If anyone doesn't-like/is-offended-by > >>politically-incorrect software "foo" in Extras, they have the right to > >>not use it and/or take their issues upstream. > > > I will note that software has been previously purged from RH > > distributions for being "incorrect" (e.g. "bitchx"). > > We're not talking about a commerical RedHat distribution, nor even > Fedora Core here, but Extras. > Well bitchx was also removed b/c it was broken and did kinda nasty things for the user who didn't configure it to the Nth degree. oh and i think unicode brokenness was the 'official' reason it got pulled. Nevertheless, I say something like enemies-of-my-mom or whatever is fine - if the upstream author gets a lot of abuse, well, that's his/her problem and I won't even remotely feel bad about it. :) -sv From iago.rubio at hispalinux.es Tue Apr 5 20:51:56 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Tue, 05 Apr 2005 22:51:56 +0200 Subject: Review Needed: autossh, bwm-ng, colortail, htop In-Reply-To: References: <20050404095718.GA8597@lisas.de> <1112611595.9581.3.camel@speedy.iagorubio.net> Message-ID: <1112734317.12600.32.camel@speedy.iagorubio.net> On Mon, 2005-04-04 at 21:19 +0200, Dag Wieers wrote: > On Mon, 4 Apr 2005, Iago Rubio wrote: > > > On Mon, 2005-04-04 at 11:57 +0200, Adrian Reber wrote: > > > I would like to import following packages into CVS. > > > > > > http://lisas.de/~adrian/rpm/autossh-1.3-1.src.rpm > > > http://lisas.de/~adrian/rpm/bwm-ng-0.5-3.src.rpm > > > http://lisas.de/~adrian/rpm/colortail-0.3.0-1.src.rpm > > > http://lisas.de/~adrian/rpm/htop-0.5-2.src.rpm > > > > > > All this packages are from Dag and I would like to keep the specfiles as > > > close as possible to Dag's version if possible. > > > > It will depend on how close Dag's spec files are to Fedora's packaging > > guidelines. > > Please look at them and then comment. I'm open to improve it where > necessary. Please Dag, no offense. I just pointed there's no way of maintaining spec files on Fedora close to X third party repository ones, if X spec files does not matches Fedora's guidelines. I was not commenting on the quality of your spec files, nor in how close they're to Fedora's guidelines. I just meant Adrian's wills of maintaining the spec files as close as possible to X version, will just depend on how X version spec files matches the Fedora's guidelines. If X-repo specs matches the Fedora's guidelines, there'll be no problem on maintaining them exactly as they're. If they does not match Fedora's guidelines, they should be changed despite of where they came from. ITOH I should admit my message was not as constructive as I'd like it to be, and its lack of explanations could let you think I was saying your packages are not of enough quality to be pushed onto Fedora. I'm sorry for this, and it was not my intention at all. I also may say, I didn't checked the spec files, and you're right in your assertion on "look at them and then comment". I will do it. Said that, I still think that none should advocate to maintain specs on Fedora close to third party ones, if those third parties does not match Fedora's packaging guidelines. Of course I'm not speaking about your repository. I hope you could understand what I mean. -- Iago Rubio From jeff at ocjtech.us Tue Apr 5 21:24:00 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 05 Apr 2005 16:24:00 -0500 Subject: More Review: Asterisk Message-ID: <1112736240.4177.22.camel@lt16586.campus.dmacc.edu> Hi, I've updated my Asterisk packages based upon the previous discussions (thanks everyone!). The packages can be found at . Highlights of the changes: 1. zaptel source package split - one package to produce the user-mode tools and libraries and one package to produce the kernel modules. 2. kernel module naming changed to 'kernel-module-zaptel-%{kernel_version}-1.%{package_version}.%{package_release}' 3. kernel modules have a virtual provides kernel-module-zaptel-version = %{package_version} 4. asterisk binary package split up into a number of sub-packages so that you don't have to install everything (which might pull in large dependencies like postgresql). 5. asterisk will run as a non-root user I have also built binary packages for FC3 (using mach). The packages also build on development but I haven't provided binary packages. Jeff Ollie -------------- 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 Apr 5 21:28:27 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Apr 2005 23:28:27 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <1112731904.22212.83.camel@ignacio.ignacio.lan> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <1112731904.22212.83.camel@ignacio.ignacio.lan> Message-ID: <20050405232827.11b19e26.bugs.michael@gmx.net> On Tue, 05 Apr 2005 16:11:44 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 21:21 +0200, Ralf Ertzinger wrote: > > Just so I do not get out of shape: may someone review > > http://ryoko.camperquake.de/fedora/enemies-of-carlotta-1.0.3-1.src.rpm ? > > %SOURCE0 uses macros. Can we please stop criticising this? It has been beaten to death in previous threads on where the "No macros in %SOURCE" guideline has come from and why/when it makes sense. In Fedora Extras, packagers are free to use macros in %SOURCE lines. From bugs.michael at gmx.net Tue Apr 5 22:29:47 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 00:29:47 +0200 Subject: Review: perl-DBD-SQLite (was: Re: Looking for a sponsor) In-Reply-To: <485bb884050320132825351809@mail.gmail.com> References: <485bb88405031617557e855e23@mail.gmail.com> <485bb884050320132825351809@mail.gmail.com> Message-ID: <20050406002947.60979abf.bugs.michael@gmx.net> On Sun, 20 Mar 2005 13:28:45 -0800, Michael Peters wrote: > I'm still looking for a sponsor. > I think slimserver needs to go into livna - but there are some perl > modules that it needs that will need to be available in extras. > > At this point I've packaged three of them (only tested in fc4t1) > In future I will also be needing perl-DBD-SQLite (I have a spec file > for it but I have not tested the package with slimserver yet) > I'm willing to maintain these perl modules so I can get slimserver > into livna - so a sponsor would be appreciated. Feedback on the perl > package spec files would also be appreciated. I've had a look at your perl-DBD-SQLite package and found the following: * Try to stay very close to the Fedora spectemplate for Perl packages as found in the fedora-rpmdevtools package in /usr/share/fedora/. Basically it's the result of what we've come up at fedora.us during Perl package QA and always finding the same packaging problems in Perl packages. As attached patch demonstrates, you should be able to take over the template for your package and also avoid things like overriding RPM's internal dependency generator or compressing manual pages yourself. The spec template also ensures that installed files (in particular DSOs) are writable and can be stripped automatically. * Missing directories: avoid creating file lists for the %files section. Often you need extra "find" expressions for missing %dir entries. Instead, include files via %perl_vendorarch or %perl_vendorlib which are the arch-specific/arch-independent root directories for Perl modules. Missing directories can be created with insufficient file access permissions depending on umask. * Missing perl :MODULE_COMPAT dependency, because it installs into Perl vendor locations. Fedora spec template has an example. * Avoid appearance of buildroot paths in the %build section. Buildroot should never get the chance to make it into compiled files. Specify buildroot paths in the %install section only. * /usr = %_prefix * Package builds without $RPM_OPT_FLAGS and hence creates a useless debuginfo package. "make OPTIMIZEFLAGS=$RPM_OPT_FLAGS" from Fedora spectemplate fixes that, too. * Move "make test" into the %check spec file section, so it could be disabled at build-time. Example in patch below. * Avoid setting the "Packager" line in the spec file, since you don't want your name appear in broken binary packages built by somebody else. Define the packager in your rpmrc. --- perl-DBD-SQLite.spec.old 2005-03-22 04:30:40.000000000 +0100 +++ perl-DBD-SQLite.spec 2005-04-06 00:15:01.000000000 +0200 @@ -1,19 +1,16 @@ -%define _use_internal_dependency_generator 0 - %define real_name DBD-SQLite -%define name perl-%{real_name} Summary: Self Contained RDBMS in a DBI Driver -Name: %{name} +Name: perl-%{real_name} Version: 1.08 -Release: 0.0.yjl.0.testing.2 +Release: 1 License: GPL or Artistic Group: System Environment/Libraries -Source: ftp://ftp.cpan.org/pub/CPAN/modules/by-module/DBD/%{real_name}-%{version}.tar.gz +Source0: ftp://ftp.cpan.org/pub/CPAN/modules/by-module/DBD/%{real_name}-%{version}.tar.gz Url: http://search.cpan.org/~msergeant/DBD-SQLite-%{version}/ -Packager: Michael A. Peters BuildRoot: %{_tmppath}/%{name}-buildroot/ BuildRequires: perl-DBI +Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) %description SQLite is a public domain RDBMS database engine that you can find at @@ -28,32 +25,28 @@ %setup -q -n %{real_name}-%{version} %build -CFLAGS="$RPM_OPT_FLAGS" perl Makefile.PL PREFIX=$RPM_BUILD_ROOT/usr INSTALLDIRS=vendor < /dev/null -make +CFLAGS="$RPM_OPT_FLAGS" perl Makefile.PL PREFIX=%{_prefix} INSTALLDIRS=vendor < /dev/null +make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" + +%check || : make test %install rm -rf $RPM_BUILD_ROOT -make install - -[ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress - -find $RPM_BUILD_ROOT \( -name perllocal.pod -o -name .packlist \) -exec rm -v {} \; - -find $RPM_BUILD_ROOT/usr -type f -print | - sed "s@^$RPM_BUILD_ROOT@@g" | - grep -v perllocal.pod | - grep -v "\.packlist" > %{name}-%{version}-filelist -if [ "$(cat %{name}-%{version}-filelist)X" = "X" ] ; then - echo "ERROR: EMPTY FILE LIST" - exit -1 -fi +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/* %clean rm -rf $RPM_BUILD_ROOT -%files -f %{name}-%{version}-filelist - +%files +%defattr(-,root,root,-) +%{perl_vendorarch}/DBD/ +%{perl_vendorarch}/auto/DBD/ +%{_mandir}/man3/* %changelog * Sun Mar 13 2005 Michael A. Peters From alexl at users.sourceforge.net Tue Apr 5 23:21:50 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 05 Apr 2005 16:21:50 -0700 Subject: Rebuild request: galeon-1.3.20 Message-ID: <1n1x9o3j3l.fsf@allele2.biol.berkeley.edu> Hi, I'm not sure if galeon is officially "orphaned", it's not listed on: http://fedoraproject.org/wiki/Extras/OrphanedPackages so I assume it's still maintained, or has otherwise fallen through the cracks. If so (or even if not), I'd like to request a build of galeon 1.3.20 against the latest mozilla update (1.7.6). It appears from: http://bugzilla.fedora.us/show_bug.cgi?id=1299 that galeon hasn't been built for over a year (March 2004) and that was against 1.3.13 on FC1! I'm not sure what the usual procedure is to request builds for maintained packages, but I also filed a new bugzilla request for this too: https://bugzilla.redhat.com/beta/show_bug.cgi?id=153937 Thanks, Alex From bugs.michael at gmx.net Tue Apr 5 23:37:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 01:37:48 +0200 Subject: Rebuild request: galeon-1.3.20 In-Reply-To: <1n1x9o3j3l.fsf@allele2.biol.berkeley.edu> References: <1n1x9o3j3l.fsf@allele2.biol.berkeley.edu> Message-ID: <20050406013748.05e16d18.bugs.michael@gmx.net> On Tue, 05 Apr 2005 16:21:50 -0700, Alex Lancaster wrote: > Hi, > > I'm not sure if galeon is officially "orphaned", it's not listed on: > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > so I assume it's still maintained, or has otherwise fallen through the > cracks. If so (or even if not), I'd like to request a build of galeon > 1.3.20 against the latest mozilla update (1.7.6). It appears from: > http://bugzilla.fedora.us/show_bug.cgi?id=1299 that galeon hasn't been > built for over a year (March 2004) and that was against 1.3.13 on FC1! You misinterpret that bug report. Galeon has not been included since FC1. Only after the import of fedora.us packages in Fedora Extras CVS it has come back to life for FC3 and newer. > I'm not sure what the usual procedure is to request builds for > maintained packages, but I also filed a new bugzilla request for this > too: > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=153937 Bugzilla is the right procedure. ;) From bugs.michael at gmx.net Tue Apr 5 23:43:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 01:43:40 +0200 Subject: Newer packages in FC-3 branch compared with devel In-Reply-To: <20050307215814.1f36e3a5.bugs.michael@gmx.net> References: <20050307215814.1f36e3a5.bugs.michael@gmx.net> Message-ID: <20050406014340.415ab8bd.bugs.michael@gmx.net> Comparing EVR of packages in CVS: alsa-tools 0:1.0.6-1 in FC-3 branch is newer than devel cfengine 0:2.1.13-4 in FC-3 branch is newer than devel netcdf 0:3.6.0-1.p1 in FC-3 branch is newer than devel From bugs.michael at gmx.net Tue Apr 5 23:51:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 01:51:53 +0200 Subject: Missing bugzilla component entries In-Reply-To: <20050323120323.61443072.bugs.michael@gmx.net> References: <20050323120323.61443072.bugs.michael@gmx.net> Message-ID: <20050406015153.5354bc43.bugs.michael@gmx.net> Bugzilla component creation can be requested here: http://fedoraproject.org/wiki/Extras/BugzillaAdmin List of modules in "devel" tree with missing bugzilla components (package owners estimated based on majority of recent changelog entries): aiksaurus : Caolan McNamara apmud : AMBIGUOUS cdlabelgen : Harald Hoyer dkms : Gary Lerhaupt enchant : AMBIGUOUS epylog : Konstantin Ryabitsev feh : Aaron Kurtz gnome-applet-netmon : Gavin Henry hfsplusutils : David Woodhouse milter-greylist : Enrico Scholz nabi : Leon Ho ncftp : Karsten Hopp notecase : Ignacio Vazquez-Abrams ots : AMBIGUOUS perl-Config-IniFiles : Jose Pedro Oliveira python-elementtree : Konstantin Ryabitsev python-kid : Konstantin Ryabitsev qemu : David Woodhouse repoview : Konstantin Ryabitsev tdl : Laurent Papier tetex-bytefield : Jose Pedro Oliveira udftools : Matthias Saou util-vserver : Enrico Scholz xfce4-mixer : Kevin Fenzi xfce4-session : Kevin Fenzi xfce4-toys : Kevin Fenzi xfce4-trigger-launcher : Kevin Fenzi xfdesktop : Kevin Fenzi xmms : Colin Walters yap : Gerard Milmeister From jwboyer at jdub.homelinux.org Wed Apr 6 01:39:26 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 05 Apr 2005 20:39:26 -0500 Subject: Suggestion: quilt In-Reply-To: <1112625934.9921.17.camel@bree.local.net> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> <1112621591.27345.23.camel@Madison.badger.com> <1112625934.9921.17.camel@bree.local.net> Message-ID: <1112751566.6160.19.camel@jdub.homelinux.org> On Mon, 2005-04-04 at 10:45 -0400, Jeremy Katz wrote: > On Mon, 2005-04-04 at 09:33 -0400, Toshio wrote: > > On Mon, 2005-04-04 at 08:47 +0200, Adrian Reber wrote: > > > How about using a trigger for the bash-completion stuff like I have seen > > > it in other packages (mpc). > > > > ...you create a different mechanism to deal with it. I was unaware of > > the trigger stuff you refer to but it looks almost right:: > > Please don't use a trigger unless they're absolutely, 100% required with > no other way around them. > > Writing a trigger that is completely future proof (which is required, > given how triggers work) is *extremely* difficult to do. Ok, latest quilt packages at http://jdub.homelinux.org/files/ I've trimmed some of the Requires, removed the Authors part from the % description, and fixed a warning that was printed when viewing the man page. The package still owns the /etc/bash_completion.d directory because I'm still not sure how to handle that. It seems to want fixing so that when quilt is removed that directory doesn't get removed as well since there might be other things in there. I still don't see what the problem is with having it own /etc/bash_completion.d/quilt instead of the whole directory. Someone care to enlighten me again? josh From iago.rubio at hispalinux.es Wed Apr 6 02:44:22 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Wed, 06 Apr 2005 04:44:22 +0200 Subject: Review Needed: autossh, bwm-ng, colortail, htop In-Reply-To: <20050405065541.GA17743@lisas.de> References: <20050404095718.GA8597@lisas.de> <1112611595.9581.3.camel@speedy.iagorubio.net> <20050405065541.GA17743@lisas.de> Message-ID: <1112755462.22669.3.camel@speedy.iagorubio.net> On Tue, 2005-04-05 at 08:55 +0200, Adrian Reber wrote: > On Mon, Apr 04, 2005 at 12:46:34PM +0200, Iago Rubio wrote: > > On Mon, 2005-04-04 at 11:57 +0200, Adrian Reber wrote: > > > I would like to import following packages into CVS. > > > > > > http://lisas.de/~adrian/rpm/autossh-1.3-1.src.rpm > > > http://lisas.de/~adrian/rpm/bwm-ng-0.5-3.src.rpm > > > http://lisas.de/~adrian/rpm/colortail-0.3.0-1.src.rpm > > > http://lisas.de/~adrian/rpm/htop-0.5-2.src.rpm > > > > > > All this packages are from Dag and I would like to keep the specfiles as > > > close as possible to Dag's version if possible. > > > > It will depend on how close Dag's spec files are to Fedora's packaging > > guidelines. > > I would say the specs are pretty close to the guidelines. I agree with you. > I have extracted the specs for easier reviews: > http://lisas.de/~adrian/rpm/autossh.spec * Consider to use -p to preserve timestamps on "install" invocation. * Consider to use the preferred Fedora's buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) * Mixed variables and macros (optimization flags), please stuck with one or another, but not both. > http://lisas.de/~adrian/rpm/bwm-ng.spec * Consider to use -p to preserve timestamps on "install" invocation. * Consider to use the preferred Fedora's buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > http://lisas.de/~adrian/rpm/colortail.spec * Consider to use the preferred Fedora's buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > http://lisas.de/~adrian/rpm/htop.spec * Consider to use -p to preserve timestamps on "install" invocation. * Consider to use the preferred Fedora's buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) * Consider to strip out irrelevant documentation: INSTALL and the philosophical NEWS file. "See the ChangeLog for news of the past. See the TODO list for news of the future. Run the program for news of the present" :) All packages rebuilds and installs fine. Related guidelines: Timestamps http://fedoraproject.org/wiki/PackagingGuidelines#head- c04ed1238a14de2b02d7fd14a7e9605bb1b10b96 Variables and macros ($RPM_OPT_FLAGS) http://fedoraproject.org/wiki/PackagingGuidelines#head- d0ada6130cf40be1244d34cc44fc38d34dd00db8 Buildroot http://fedoraproject.org/wiki/PackagingGuidelines#head-29431b817fcad64ff7483ca37fb8d69bd31c0da7 Documentation http://fedoraproject.org/wiki/PackagingGuidelines#head-9e9cf3221a30246219863f1d2366e36cb580debc Regards. -- Iago Rubio From ivazquez at ivazquez.net Wed Apr 6 03:09:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 23:09:42 -0400 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050405232827.11b19e26.bugs.michael@gmx.net> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <1112731904.22212.83.camel@ignacio.ignacio.lan> <20050405232827.11b19e26.bugs.michael@gmx.net> Message-ID: <1112756982.22212.85.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 23:28 +0200, Michael Schwendt wrote: > On Tue, 05 Apr 2005 16:11:44 -0400, Ignacio Vazquez-Abrams wrote: > > %SOURCE0 uses macros. > > Can we please stop criticising this? Feel free to remove it from the Packaging Guidelines. -- 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 alexl at users.sourceforge.net Wed Apr 6 04:10:34 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 05 Apr 2005 21:10:34 -0700 Subject: Rebuild request: galeon-1.3.20 In-Reply-To: <20050406013748.05e16d18.bugs.michael@gmx.net> (Michael Schwendt's message of "Wed, 6 Apr 2005 01:37:48 +0200") References: <1n1x9o3j3l.fsf@allele2.biol.berkeley.edu> <20050406013748.05e16d18.bugs.michael@gmx.net> Message-ID: On Tue, 05 Apr 2005 16:21:50 -0700, Alex Lancaster wrote: >> Hi, I'm not sure if galeon is officially "orphaned", it's not listed >> on: >> http://fedoraproject.org/wiki/Extras/OrphanedPackages >> so I assume it's still maintained, or has otherwise fallen through >> the cracks. If so (or even if not), I'd like to request a build of >> galeon 1.3.20 against the latest mozilla update (1.7.6). It >> appears from: http://bugzilla.fedora.us/show_bug.cgi?id=1299 that >> galeon hasn't been built for over a year (March 2004) and that was >> against 1.3.13 on FC1! >>>>> "MS" == Michael Schwendt writes: MS> You misinterpret that bug report. Galeon has not been included MS> since FC1. Only after the import of fedora.us packages in Fedora MS> Extras CVS it has come back to life for FC3 and newer. Sorry, I was aware that it had not been included since FC1, I was simply quoting that bugzilla.fedora.us report since it seemed to be last discussion of galeon in Fedora that I could find and that it seems that it had neither been orphaned for "official Fedora Extras" nor built in the meantime. >> I'm not sure what the usual procedure is to request builds for >> maintained packages, but I also filed a new bugzilla request for >> this too: >> >> https://bugzilla.redhat.com/beta/show_bug.cgi?id=153937 MS> Bugzilla is the right procedure. ;) OK, thanks! Is there a wiki page that I should also put a note on? Alex From toshio at tiki-lounge.com Wed Apr 6 04:30:06 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 06 Apr 2005 00:30:06 -0400 Subject: Suggestion: quilt In-Reply-To: <1112751566.6160.19.camel@jdub.homelinux.org> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> <1112621591.27345.23.camel@Madison.badger.com> <1112625934.9921.17.camel@bree.local.net> <1112751566.6160.19.camel@jdub.homelinux.org> Message-ID: <1112761806.12543.35.camel@Madison.badger.com> On Tue, 2005-04-05 at 20:39 -0500, Josh Boyer wrote: > On Mon, 2005-04-04 at 10:45 -0400, Jeremy Katz wrote: > > On Mon, 2005-04-04 at 09:33 -0400, Toshio wrote: > > > On Mon, 2005-04-04 at 08:47 +0200, Adrian Reber wrote: > > > > How about using a trigger for the bash-completion stuff like I have seen > > > > it in other packages (mpc). > > > > > > ...you create a different mechanism to deal with it. I was unaware of > > > the trigger stuff you refer to but it looks almost right:: > > > > Please don't use a trigger unless they're absolutely, 100% required with > > no other way around them. > > > > Writing a trigger that is completely future proof (which is required, > > given how triggers work) is *extremely* difficult to do. > > Ok, latest quilt packages at http://jdub.homelinux.org/files/ > > I've trimmed some of the Requires, removed the Authors part from the % > description, and fixed a warning that was printed when viewing the man > page. > > The package still owns the /etc/bash_completion.d directory because I'm > still not sure how to handle that. It seems to want fixing so that when > quilt is removed that directory doesn't get removed as well since there > might be other things in there. > If there's other things in it, the directory will be left so this isn't an issue. > I still don't see what the problem is with having it > own /etc/bash_completion.d/quilt instead of the whole directory. > Someone care to enlighten me again? > If bash_completion isn't installed on the system, quilt will create /etc/bash_completion.d. When quilt is erased, it will leave the empty bash_completion.d directory in /etc with nothing owning it. If bash_completion.d is installed on the system but is uninstalled before quilt is uninstalled the same thing occurs (because bash_completion is unable to remove the directory while other files are inside.) The reason this isn't needed for say /usr/share/man/man1 is that there's a string of dependent packages (quilt->glibc->basesystem->filesystem) for quilt that leads to the filesystem package which owns it. Similarly, for python packages one doesn't have to own /usr/lib/python2.4/site-packages because they depend on python which owns that directory. So if your package's dependency chain leads to a package which owns the directory in question, you don't need to own it. Otherwise you need to. Look under the %files heading on this page:: http://www.fedora.redhat.com/participate/developers-guide/ch-rpm- building.html for more information. -Toshio -- ________S_________U_________B_________L_________I_________M_________E________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 leemhuis.info Wed Apr 6 04:43:28 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 06 Apr 2005 06:43:28 +0200 Subject: Newer packages in FC-3 branch compared with devel In-Reply-To: <20050406014340.415ab8bd.bugs.michael@gmx.net> References: <20050307215814.1f36e3a5.bugs.michael@gmx.net> <20050406014340.415ab8bd.bugs.michael@gmx.net> Message-ID: <1112762608.10953.0.camel@thl.ct.heise.de> Am Mittwoch, den 06.04.2005, 01:43 +0200 schrieb Michael Schwendt: > Comparing EVR of packages in CVS: > > alsa-tools 0:1.0.6-1 in FC-3 branch is newer than devel Known and should be fixed soon. Cu thl From skvidal at phy.duke.edu Wed Apr 6 05:29:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 01:29:34 -0400 Subject: xmms cleanup Message-ID: <1112765374.10327.18.camel@cutter> Hey Folks, I know I'm not supposed to but I went ahead and built xmms for extras development in order to get some folks to pipe down. However, I'd like to go ahead and get a review of this package done. spec file is here: http://cvs.fedora.redhat.com/viewcvs/devel/xmms/xmms.spec?root=extras&rev=1.3&view=auto I cleaned up some obvious things and I straightened out the Sources and Patches so they are sequentially numbered and consistent again. Other things I missed? Thanks, -sv From ivazquez at ivazquez.net Wed Apr 6 05:42:34 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 01:42:34 -0400 Subject: xmms cleanup In-Reply-To: <1112765374.10327.18.camel@cutter> References: <1112765374.10327.18.camel@cutter> Message-ID: <1112766155.22212.106.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 01:29 -0400, seth vidal wrote: > Other things I missed? - Don't need the explicit Requires on gtk+ - PreReq instead of Requires(pre) ? Conflicts < instead of Requires >= ? No Changelog-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 skvidal at phy.duke.edu Wed Apr 6 06:01:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 02:01:17 -0400 Subject: xmms cleanup In-Reply-To: <1112766155.22212.106.camel@ignacio.ignacio.lan> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> Message-ID: <1112767277.10327.24.camel@cutter> > - Don't need the explicit Requires on gtk+ fixed. > - PreReq instead of Requires(pre) fixed. > ? Conflicts < instead of Requires >= I just removed the conflict as it seems a bit old, now and added in a Requires arts >= 1.3.0 > ? No Changelog-RPM I don't understand what this means. Thanks! -sv From skvidal at fedoraproject.org Wed Apr 6 06:07:01 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 06 Apr 2005 02:07:01 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1112767621.10327.28.camel@cutter> hi folks, things built for Fedora Extras Development: audacity lighttpd ots python-amara python-HTMLgen xmms zziplib thanks, -sv -------------- 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 Apr 6 06:15:46 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 02:15:46 -0400 Subject: xmms cleanup In-Reply-To: <1112767277.10327.24.camel@cutter> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> Message-ID: <1112768146.22212.110.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 02:01 -0400, seth vidal wrote: > > ? No Changelog-RPM > I don't understand what this means. A couple of days ago Mike Harris truncated the xorg-x11 changelog in the spec file. Instead of losing the previous entries he moved them into a separate file, CHANGELOG-rpm. http://cvs.fedora.redhat.com/viewcvs/devel/xorg-x11/CHANGELOG-rpm? rev=1.1&view=log I'm not saying that it's required, but it may be useful to have instead of just losing it outright. -- 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 Wed Apr 6 06:25:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 02:25:14 -0400 Subject: xmms cleanup In-Reply-To: <1112768146.22212.110.camel@ignacio.ignacio.lan> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <1112768146.22212.110.camel@ignacio.ignacio.lan> Message-ID: <1112768714.10327.34.camel@cutter> On Wed, 2005-04-06 at 02:15 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-06 at 02:01 -0400, seth vidal wrote: > > > ? No Changelog-RPM > > I don't understand what this means. > > A couple of days ago Mike Harris truncated the xorg-x11 changelog in the > spec file. Instead of losing the previous entries he moved them into a > separate file, CHANGELOG-rpm. > > http://cvs.fedora.redhat.com/viewcvs/devel/xorg-x11/CHANGELOG-rpm? > rev=1.1&view=log > > I'm not saying that it's required, but it may be useful to have instead > of just losing it outright. oh, okay. Take a look at the items I removed. I felt pretty comfortable doing so b/c: 1. they're still in cvs. 2. they're, well, really old. -sv From skvidal at fedoraproject.org Wed Apr 6 07:07:00 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 06 Apr 2005 03:07:00 -0400 Subject: Fedora Extras 3 Package Report Message-ID: <1112771220.10327.39.camel@cutter> Built: alsa-tools imlib2 lighttpd perl-Authen-SASL perl-Config-IniFiles revelation Errors: python-reportlab - unhappy on x86_64: /usr/lib64 errors See http://fedoraproject.org/wiki/Extras for more information. -sv -------------- 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 g.hollestelle at gmail.com Wed Apr 6 09:27:56 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Wed, 6 Apr 2005 11:27:56 +0200 Subject: Review request: python-cherrypy and python-cherrytemplate In-Reply-To: <1112644711.12252.24.camel@ignacio.ignacio.lan> References: <95da2d2905032307391f772092@mail.gmail.com> <20050323165945.2e2fdd92.bugs.michael@gmx.net> <95da2d290503240150324a28f9@mail.gmail.com> <1112644711.12252.24.camel@ignacio.ignacio.lan> Message-ID: <95da2d2905040602271bb883f9@mail.gmail.com> On Apr 4, 2005 9:58 PM, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-03-24 at 10:50 +0100, Gijs Hollestelle wrote: > > Anyone else who is interested in these packages and wants to take a > > look at them? > > A full-fledged review is a bit premature, but I'll sponsor them for > import. The pyver definition threw me for a loop when I first looked at > it, but it's fine. Thank you very much, how should I proceed now? I have applied for CVS access (I already had a sponsor) but have not heard anything back about that yet (only applied two days ago). Should I wait for the paperwork to go through before this can be added to extras or is it possible that someone else imports it now and possibly applies patches send by email until the CVS account is created? Greets, Gijs From bugs.michael at gmx.net Wed Apr 6 09:37:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 11:37:38 +0200 Subject: Rebuild request: galeon-1.3.20 In-Reply-To: References: <1n1x9o3j3l.fsf@allele2.biol.berkeley.edu> <20050406013748.05e16d18.bugs.michael@gmx.net> Message-ID: <20050406113738.110ea847.bugs.michael@gmx.net> On Tue, 05 Apr 2005 21:10:34 -0700, Alex Lancaster wrote: > Sorry, I was aware that it had not been included since FC1, I was > simply quoting that bugzilla.fedora.us report since it seemed to be > last discussion of galeon in Fedora that I could find and that it > seems that it had neither been orphaned for "official Fedora Extras" > nor built in the meantime. Fedora Extras CVS is the place of activity. 1.3.20 is in there since March 16th. > >> I'm not sure what the usual procedure is to request builds for > >> maintained packages, but I also filed a new bugzilla request for > >> this too: > >> > >> https://bugzilla.redhat.com/beta/show_bug.cgi?id=153937 > > MS> Bugzilla is the right procedure. ;) > > OK, thanks! Is there a wiki page that I should also put a note on? No. From bugs.michael at gmx.net Wed Apr 6 09:46:16 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 11:46:16 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <1112756982.22212.85.camel@ignacio.ignacio.lan> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <1112731904.22212.83.camel@ignacio.ignacio.lan> <20050405232827.11b19e26.bugs.michael@gmx.net> <1112756982.22212.85.camel@ignacio.ignacio.lan> Message-ID: <20050406114616.4b0fcd71.bugs.michael@gmx.net> On Tue, 05 Apr 2005 23:09:42 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 23:28 +0200, Michael Schwendt wrote: > > On Tue, 05 Apr 2005 16:11:44 -0400, Ignacio Vazquez-Abrams wrote: > > > %SOURCE0 uses macros. > > > > Can we please stop criticising this? > > Feel free to remove it from the Packaging Guidelines. Going to put it onto my todo list to get that section removed or rephrased. A lot of what you see on the "Packaging Guidelines" page in the wiki has been copied from fedora.us guidelines. In this particular case, the PackagingHints page: http://www.fedora.us/wiki/PackagingHints#macros That section is misleading and not a package quality criterion. Fedora.us has had different requirements. From ivazquez at ivazquez.net Wed Apr 6 09:48:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 05:48:35 -0400 Subject: Review request: python-cherrypy and python-cherrytemplate In-Reply-To: <95da2d2905040602271bb883f9@mail.gmail.com> References: <95da2d2905032307391f772092@mail.gmail.com> <20050323165945.2e2fdd92.bugs.michael@gmx.net> <95da2d290503240150324a28f9@mail.gmail.com> <1112644711.12252.24.camel@ignacio.ignacio.lan> <95da2d2905040602271bb883f9@mail.gmail.com> Message-ID: <1112780915.3405.1.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 11:27 +0200, Gijs Hollestelle wrote: > Should I wait for the paperwork to go through before this can be added > to extras or is it possible that someone else imports it now and > possibly applies patches send by email until the CVS account is > created? I sponsored the packages, so I'll go ahead and import. -- 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 jwboyer at jdub.homelinux.org Wed Apr 6 11:15:57 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Apr 2005 06:15:57 -0500 Subject: Suggestion: quilt In-Reply-To: <1112761806.12543.35.camel@Madison.badger.com> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> <1112621591.27345.23.camel@Madison.badger.com> <1112625934.9921.17.camel@bree.local.net> <1112751566.6160.19.camel@jdub.homelinux.org> <1112761806.12543.35.camel@Madison.badger.com> Message-ID: <1112786158.6160.21.camel@jdub.homelinux.org> On Wed, 2005-04-06 at 00:30 -0400, Toshio wrote: > > > > Ok, latest quilt packages at http://jdub.homelinux.org/files/ > > > > I've trimmed some of the Requires, removed the Authors part from the % > > description, and fixed a warning that was printed when viewing the man > > page. > > > > The package still owns the /etc/bash_completion.d directory because I'm > > still not sure how to handle that. It seems to want fixing so that when > > quilt is removed that directory doesn't get removed as well since there > > might be other things in there. > > > If there's other things in it, the directory will be left so this isn't > an issue. Good. I thought that at first, but then confused myself :). > > > I still don't see what the problem is with having it > > own /etc/bash_completion.d/quilt instead of the whole directory. > > Someone care to enlighten me again? > > > If bash_completion isn't installed on the system, quilt will > create /etc/bash_completion.d. When quilt is erased, it will leave the > empty bash_completion.d directory in /etc with nothing owning it. If > bash_completion.d is installed on the system but is uninstalled before > quilt is uninstalled the same thing occurs (because bash_completion is > unable to remove the directory while other files are inside.) > > The reason this isn't needed for say /usr/share/man/man1 is that there's > a string of dependent packages (quilt->glibc->basesystem->filesystem) > for quilt that leads to the filesystem package which owns it. > Similarly, for python packages one doesn't have to > own /usr/lib/python2.4/site-packages because they depend on python which > owns that directory. > > So if your package's dependency chain leads to a package which owns the > directory in question, you don't need to own it. Otherwise you need to. > > Look under the %files heading on this page:: > http://www.fedora.redhat.com/participate/developers-guide/ch-rpm- > building.html > for more information. Ok. Thanks for the tip. Much appreciated. I'll leave the spec file as-is then. josh From fedora at camperquake.de Wed Apr 6 11:29:14 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 6 Apr 2005 13:29:14 +0200 Subject: Handling of Bugzilla entries as a maintainer. Message-ID: <20050406132914.27a855c0@nausicaa.camperquake.de> Hi. So I just got the first bug assigned to a package I maintain in FE. I have done plenty of bugs from the reporter side, but this one is new to me. Is there anything special to be done before closing a bug (the solution of this special case is clear to be)? What about QA? Thanks. -- The Boston University Bridge (on Commonwealth Avenue, Boston, Massachusetts) is the only place in the world where a boat can sail under a train driving under a car driving under an airplane. From bugs.michael at gmx.net Wed Apr 6 11:56:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 13:56:10 +0200 Subject: Handling of Bugzilla entries as a maintainer. In-Reply-To: <20050406132914.27a855c0@nausicaa.camperquake.de> References: <20050406132914.27a855c0@nausicaa.camperquake.de> Message-ID: <20050406135610.69191702.bugs.michael@gmx.net> On Wed, 6 Apr 2005 13:29:14 +0200, Ralf Ertzinger wrote: > Hi. > > So I just got the first bug assigned to a package I maintain in FE. I have done > plenty of bugs from the reporter side, but this one is new to me. Is there > anything special to be done before closing a bug (the solution of this special > case is clear to be)? What about QA? No special requirements so far. If you have doubts, request comments by posting to this list (as you've done). The RFE bug you refer to could be closed as DEFERRED, because a FLAC plugin for BMP does not exist (except for a hacked unofficial XMMS FLAC plugin). It's nothing you can fix unless you choose to do a port of the plugin yourself or extract and package the hacked plugin as an experimental "bmp-flac". From ivazquez at ivazquez.net Wed Apr 6 12:10:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 08:10:35 -0400 Subject: Review needed: notecase Message-ID: <1112789435.3405.11.camel@ignacio.ignacio.lan> notecase: A hierarchical note manager NoteCase is a hierarchical note manager (aka. outliner). It helps you organize your everyday text notes into a single document, with individual notes placed in the tree-like structure (each note can have its sub-notes, ...). To ensure your privacy, encrypted document format is supported, along with standard unencrypted format. -- 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 Apr 6 12:10:36 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 08:10:36 -0400 Subject: Request for sponsor: gnet In-Reply-To: <1112216349.8866.13.camel@ignacio.ignacio.lan> References: <1112216349.8866.13.camel@ignacio.ignacio.lan> Message-ID: <1112789436.3405.13.camel@ignacio.ignacio.lan> On Wed, 2005-03-30 at 15:59 -0500, Ignacio Vazquez-Abrams wrote: > gnet: A simple network library built upon glib Anyone? Yes? No? -- 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 Apr 6 12:10:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 08:10:38 -0400 Subject: Request for sponsor: OpenEXR In-Reply-To: <1112240849.8866.35.camel@ignacio.ignacio.lan> References: <1112240849.8866.35.camel@ignacio.ignacio.lan> Message-ID: <1112789438.3405.15.camel@ignacio.ignacio.lan> On Wed, 2005-03-30 at 22:47 -0500, Ignacio Vazquez-Abrams wrote: > OpenEXR: A high dynamic-range (HDR) image file format Anyone? Yes? No? -- 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 Apr 6 12:10:41 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 08:10:41 -0400 Subject: RFC: Clearlooks BigPack In-Reply-To: <1112269079.8866.50.camel@ignacio.ignacio.lan> References: <1112269079.8866.50.camel@ignacio.ignacio.lan> Message-ID: <1112789441.3405.16.camel@ignacio.ignacio.lan> On Thu, 2005-03-31 at 06:37 -0500, Ignacio Vazquez-Abrams wrote: > I can come up with a package for it later today, but I just wanted to > toss this out here in order to get input as to how to proceed. In that case I'll go ahead and build the package then submit it for sponsorship. -- 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 rdieter at math.unl.edu Wed Apr 6 12:11:16 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Apr 2005 07:11:16 -0500 Subject: xmms cleanup In-Reply-To: <1112766155.22212.106.camel@ignacio.ignacio.lan> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> Message-ID: <4253D1E4.6070907@math.unl.edu> Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-06 at 01:29 -0400, seth vidal wrote: >>Other things I missed? > - Don't need the explicit Requires on gtk+ > - PreReq instead of Requires(pre) Why, what's wrong with Requires(pre)? -- Rex From fedora at camperquake.de Wed Apr 6 12:11:32 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 6 Apr 2005 14:11:32 +0200 Subject: Handling of Bugzilla entries as a maintainer. In-Reply-To: <20050406135610.69191702.bugs.michael@gmx.net> References: <20050406132914.27a855c0@nausicaa.camperquake.de> <20050406135610.69191702.bugs.michael@gmx.net> Message-ID: <20050406141132.101dc693@nausicaa.camperquake.de> Moin. Michael Schwendt wrote: > The RFE bug you refer to could be closed as DEFERRED, because a FLAC > plugin for BMP does not exist (except for a hacked unofficial XMMS FLAC > plugin). It's nothing you can fix unless you choose to do a port of the > plugin yourself or extract and package the hacked plugin as an > experimental "bmp-flac". I was thinking of doing the latter. I'll see how ugly that gets. -- I'm not crazy, I've just been in a very bad mood for 30 years. From ivazquez at ivazquez.net Wed Apr 6 12:14:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 08:14:00 -0400 Subject: xmms cleanup In-Reply-To: <4253D1E4.6070907@math.unl.edu> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <4253D1E4.6070907@math.unl.edu> Message-ID: <1112789640.3405.17.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 07:11 -0500, Rex Dieter wrote: > Ignacio Vazquez-Abrams wrote: > > - PreReq instead of Requires(pre) > > Why, what's wrong with Requires(pre)? I meant that it uses ... instead of .... Requires(pre) is the preferred form. -- 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 Apr 6 13:16:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 15:16:25 +0200 Subject: (!) CVS devel release bump at 22:00 UTC Message-ID: <20050406151625.5121f266.bugs.michael@gmx.net> As a followup to the February "rawhide/fc4 extras builds" thread on fedora-maintainers list and today's "Rebuilding Extras" thread on fedora-test-list: Fedora Extras CVS "devel" release bump of all packages, which have an E:V-R equal to "FC-3" branch, will happen today 22:00 UTC (0:00 CEST), Subscribers may want to disable commits-list mail delivery to avoid the "spam". ;) From skvidal at phy.duke.edu Wed Apr 6 13:44:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 09:44:45 -0400 Subject: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <20050406151625.5121f266.bugs.michael@gmx.net> References: <20050406151625.5121f266.bugs.michael@gmx.net> Message-ID: <1112795085.10327.53.camel@cutter> On Wed, 2005-04-06 at 15:16 +0200, Michael Schwendt wrote: > As a followup to the February "rawhide/fc4 extras builds" thread on fedora-maintainers > list and today's "Rebuilding Extras" thread on fedora-test-list: > > Fedora Extras CVS "devel" release bump of all packages, which have an > E:V-R equal to "FC-3" branch, will happen today 22:00 UTC (0:00 CEST), > Subscribers may want to disable commits-list mail delivery to avoid > the "spam". ;) > Cool. I'll grab all the packages changed from the list subjects and use that as a build list, then. thanks. -sv From kaboom at oobleck.net Wed Apr 6 14:10:55 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 6 Apr 2005 10:10:55 -0400 (EDT) Subject: maintaining orphaned packages Message-ID: I'm willing to maintain x3270 and cyrus-imapd John Dennis (Red Hat maintainer of cyrus-imapd for RHEL) might want to maintain it for FE as well. If he doesn't though, I'll do it for FE A somewhat cleaned up x3270 based on the last one in -devel CVS is at for review later, chris From bugs.michael at gmx.net Wed Apr 6 14:14:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Apr 2005 16:14:42 +0200 Subject: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <1112795085.10327.53.camel@cutter> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> Message-ID: <20050406161442.60ad3cdb.bugs.michael@gmx.net> On Wed, 06 Apr 2005 09:44:45 -0400, seth vidal wrote: > On Wed, 2005-04-06 at 15:16 +0200, Michael Schwendt wrote: > > As a followup to the February "rawhide/fc4 extras builds" thread on fedora-maintainers > > list and today's "Rebuilding Extras" thread on fedora-test-list: > > > > Fedora Extras CVS "devel" release bump of all packages, which have an > > E:V-R equal to "FC-3" branch, will happen today 22:00 UTC (0:00 CEST), > > Subscribers may want to disable commits-list mail delivery to avoid > > the "spam". ;) > > > > Cool. I'll grab all the packages changed from the list subjects and use > that as a build list, then. > > thanks. I could create a list with the names of all bumped packages (and optionally an exclude list of all packages not touched). From skvidal at phy.duke.edu Wed Apr 6 14:19:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 10:19:37 -0400 Subject: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <20050406161442.60ad3cdb.bugs.michael@gmx.net> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> Message-ID: <1112797177.10327.65.camel@cutter> > I could create a list with the names of all bumped packages (and > optionally an exclude list of all packages not touched). That'd be cool. I was just going to do a regex from my commits mailbox. :) -sv From ville.skytta at iki.fi Wed Apr 6 14:57:28 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Apr 2005 17:57:28 +0300 Subject: xmms cleanup In-Reply-To: <1112789640.3405.17.camel@ignacio.ignacio.lan> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <4253D1E4.6070907@math.unl.edu> <1112789640.3405.17.camel@ignacio.ignacio.lan> Message-ID: <1112799448.22818.76.camel@bobcat.mine.nu> On Wed, 2005-04-06 at 08:14 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-06 at 07:11 -0500, Rex Dieter wrote: > > Ignacio Vazquez-Abrams wrote: > > > - PreReq instead of Requires(pre) > > > > Why, what's wrong with Requires(pre)? > > I meant that it uses ... instead of .... Requires(pre) is the preferred > form. Nope, they are different. Requires(pre) means "required for running the %pre scriptlet". xmms does not have a %pre scriptlet so it's clearly incorrect there. Just use plain Requires. PreReq used to mean something in addition to Requires, but unless I'm mistaken, they're equivalent nowadays. From nphilipp at redhat.com Wed Apr 6 15:07:08 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 06 Apr 2005 17:07:08 +0200 Subject: rpms/bzflag/devel bzflag.spec,1.7,1.8 In-Reply-To: <1112797341.20996.128.camel@mccallum.corsepiu.local> References: <200504061327.j36DRuMW031403@cvs-int.fedora.redhat.com> <1112797341.20996.128.camel@mccallum.corsepiu.local> Message-ID: <1112800028.22249.18.camel@wombat.tiptoe.de> On Wed, 2005-04-06 at 16:22 +0200, Ralf Corsepius wrote: > On Wed, 2005-04-06 at 09:27 -0400, Nils Philippsen wrote: > > Author: nphilipp > > > > Update of /cvs/extras/rpms/bzflag/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31395 > > > > Modified Files: > > bzflag.spec > > Log Message: > > build with adns > > build require minimum version of xorg-x11-devel to hopefully solve the GL building problems > > > > > > > > Index: bzflag.spec > > =================================================================== > > RCS file: /cvs/extras/rpms/bzflag/devel/bzflag.spec,v > > retrieving revision 1.7 > > retrieving revision 1.8 > > diff -u -r1.7 -r1.8 > > --- bzflag.spec 30 Mar 2005 15:01:06 -0000 1.7 > > +++ bzflag.spec 6 Apr 2005 13:27:54 -0000 1.8 > > @@ -11,14 +11,13 @@ > > Source: http://ftp.bzflag.org/bzflag/bzflag-%{version}%{?date:.%{date}}.tar.bz2 > > Source1: bzflag.desktop > > BuildRoot: %{_tmppath}/%{name}-%{version}-root-%(%{__id_u} -n) > > -BuildRequires: xorg-x11-devel > > -# work around missing dependency in xorg-x11-devel: > > -BuildRequires: libGL.so.1 libGLU.so.1 > > +BuildRequires: xorg-x11-devel >= 6.8.2-14 > > Veto. I don't think there is such a thing as a formal(ized?) veto of a specific commit (of a package that is already in Extras that is, anybody please correct me if I'm wrong here). Besides, out of common courtesy you could have used different phrasing -- "use BuildRequires: xorg-x11-devel libGL-devel libGLU-devel instead" sounds so much more helpful, don't you think? > > +- build require minimum version of xorg-x11-devel to hopefully solve > > the GL building problems > > AFAIS, you have just removed GL entirely. You don't seem to have looked at the changes in xorg-x11-devel >= 6.8.2-14. While the build requirement above isn't formally correct, it would work at the moment. I'll commit appropriate changes momentarily. 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 skvidal at phy.duke.edu Wed Apr 6 15:11:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 11:11:50 -0400 Subject: rpms/bzflag/devel bzflag.spec,1.7,1.8 In-Reply-To: <1112800028.22249.18.camel@wombat.tiptoe.de> References: <200504061327.j36DRuMW031403@cvs-int.fedora.redhat.com> <1112797341.20996.128.camel@mccallum.corsepiu.local> <1112800028.22249.18.camel@wombat.tiptoe.de> Message-ID: <1112800310.10327.79.camel@cutter> > > > +BuildRequires: xorg-x11-devel >= 6.8.2-14 > > > > Veto. > > I don't think there is such a thing as a formal(ized?) veto of a > specific commit (of a package that is already in Extras that is, anybody > please correct me if I'm wrong here). > > Besides, out of common courtesy you could have used different phrasing > -- "use BuildRequires: xorg-x11-devel libGL-devel libGLU-devel instead" > sounds so much more helpful, don't you think? > There's not a formal veto. There's a legal veto but that's different. -sv From ville.skytta at iki.fi Wed Apr 6 15:10:50 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 06 Apr 2005 18:10:50 +0300 Subject: Suggestion: quilt In-Reply-To: <1112786158.6160.21.camel@jdub.homelinux.org> References: <1112322062.12105.44.camel@jdub.homelinux.org> <1112550875.5995.15.camel@Madison.badger.com> <20050404064710.GA8076@lisas.de> <1112621591.27345.23.camel@Madison.badger.com> <1112625934.9921.17.camel@bree.local.net> <1112751566.6160.19.camel@jdub.homelinux.org> <1112761806.12543.35.camel@Madison.badger.com> <1112786158.6160.21.camel@jdub.homelinux.org> Message-ID: <1112800250.22818.87.camel@bobcat.mine.nu> On Wed, 2005-04-06 at 06:15 -0500, Josh Boyer wrote: > On Wed, 2005-04-06 at 00:30 -0400, Toshio wrote: > > > > > > I still don't see what the problem is with having it > > > own /etc/bash_completion.d/quilt instead of the whole directory. > > > Someone care to enlighten me again? > > > > > If bash_completion isn't installed on the system, quilt will > > create /etc/bash_completion.d. When quilt is erased, it will leave the > > empty bash_completion.d directory in /etc with nothing owning it. Additionally, unowned dirs will be created using default permissions, and are affected by umask. With restrictive umask in place that will lead to inaccessible dirs and b0rkage. From tcallawa at redhat.com Wed Apr 6 15:19:31 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Apr 2005 10:19:31 -0500 Subject: Request for sponsor: bioperl and its dependencies In-Reply-To: <1112712804.2818.5.camel@jade.biology.duke.edu> References: <1112630793.2789.0.camel@jade.biology.duke.edu> <20050404165032.GC2742@plain.rackshack.net> <1112635865.2789.5.camel@jade.biology.duke.edu> <1112712804.2818.5.camel@jade.biology.duke.edu> Message-ID: <1112800771.4899.26.camel@localhost.localdomain> On Tue, 2005-04-05 at 10:53 -0400, Hunter Matthews wrote: > On Mon, 2005-04-04 at 13:31, Hunter Matthews wrote: > > > bioperl*-2 and the new specfile are now included: > > http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ > > I've applied the patches/suggestions supplied on list - is anyone willing > to sponsor these packages? Yes. I'll sponsor. ~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 jpo at di.uminho.pt Wed Apr 6 15:47:37 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Wed, 06 Apr 2005 16:47:37 +0100 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <1112390969.2932.142.camel@jade.biology.duke.edu> References: <1112390969.2932.142.camel@jade.biology.duke.edu> Message-ID: <42540499.8090408@di.uminho.pt> Hunter, A couple of notes about the specfiles: * License Most of the license information appears to be incomplete. If the copyright section says that the module is available on the same terms as perl itself, the license is "GPL or Artistic". License: GPL or Artistic * URL If the module is available in CPAN don't use a URL that contains the author id and the module version. Example: Use http://search.cpan.org/dist/Heap/ instead of http://search.cpan.org/~jmm/Heap-0.70/ By the way you need to update Heap to version 0.71. * Source tarball URL If the module is available in CPAN there is a shorter URL. Example: use http://www.cpan.org/authors/id/J/JM/JMM/Heap-0.70.tar.gz instead http://search.cpan.org/CPAN/authors/id/J/JM/JMM/Heap-0.70.tar.gz * %build section When a module is noarch you can drop CFLAGS and OPTIMIZE. Will try to give a second look later (I still haven't built the RPMS). (I wish we had a Bugzilla for QA). 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 * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From zuirdj at gmail.com Wed Apr 6 15:51:51 2005 From: zuirdj at gmail.com (Zuir DJ) Date: Wed, 6 Apr 2005 11:51:51 -0400 Subject: Handling of Bugzilla entries as a maintainer. In-Reply-To: <20050406141132.101dc693@nausicaa.camperquake.de> References: <20050406132914.27a855c0@nausicaa.camperquake.de> <20050406135610.69191702.bugs.michael@gmx.net> <20050406141132.101dc693@nausicaa.camperquake.de> Message-ID: On Apr 6, 2005 8:11 AM, Ralf Ertzinger wrote: > Moin. > > Michael Schwendt wrote: > > > The RFE bug you refer to could be closed as DEFERRED, because a FLAC > > plugin for BMP does not exist (except for a hacked unofficial XMMS FLAC > > plugin). It's nothing you can fix unless you choose to do a port of the > > plugin yourself or extract and package the hacked plugin as an > > experimental "bmp-flac". > > I was thinking of doing the latter. I'll see how ugly that gets. Hi. I filled the bug, thinking the enhancement was more easy. xmms-flac was till yesterday in core and I though in a easy port to bmp or in a native flac support. Thanks for the effort and for the great work that you are doing. -- Zuirdj From skvidal at fedoraproject.org Wed Apr 6 16:06:07 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 06 Apr 2005 12:06:07 -0400 Subject: Fedora Extras 3 Package Report Message-ID: <1112803567.10327.86.camel@cutter> More packages: hamlib gpredict ktrack -sv -------------- 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 fedoraproject.org Wed Apr 6 16:06:49 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 06 Apr 2005 12:06:49 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1112803609.10327.88.camel@cutter> xmms bzflag hamlib ktrack -sv -------------- 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 thm at duke.edu Wed Apr 6 16:32:14 2005 From: thm at duke.edu (Hunter Matthews) Date: Wed, 06 Apr 2005 12:32:14 -0400 Subject: Request for sponsor: bioperl and its dependencies In-Reply-To: <1112800771.4899.26.camel@localhost.localdomain> References: <1112630793.2789.0.camel@jade.biology.duke.edu> <20050404165032.GC2742@plain.rackshack.net> <1112635865.2789.5.camel@jade.biology.duke.edu> <1112712804.2818.5.camel@jade.biology.duke.edu> <1112800771.4899.26.camel@localhost.localdomain> Message-ID: <1112805134.2839.9.camel@jade.biology.duke.edu> On Wed, 2005-04-06 at 11:19, Tom 'spot' Callaway wrote: > On Tue, 2005-04-05 at 10:53 -0400, Hunter Matthews wrote: > > On Mon, 2005-04-04 at 13:31, Hunter Matthews wrote: > > > > > bioperl*-2 and the new specfile are now included: > > > http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/srpms/ > > > > I've applied the patches/suggestions supplied on list - is anyone willing > > to sponsor these packages? > > Yes. I'll sponsor. > Ok, I just got some more comments about needed changes -- given the number of packages, I'll update them here and wait for CVS access. > ~spot -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From notting at redhat.com Wed Apr 6 16:32:36 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Apr 2005 12:32:36 -0400 Subject: xmms cleanup In-Reply-To: <1112767277.10327.24.camel@cutter> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> Message-ID: <20050406163236.GH15748@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > > ? Conflicts < instead of Requires >= > I just removed the conflict as it seems a bit old, now and added in a > Requires arts >= 1.3.0 This is intentional; it conflicts with older arts, but doesn't require you to install arts (at least, it shouldn't.) Bill From skvidal at phy.duke.edu Wed Apr 6 16:37:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 12:37:00 -0400 Subject: xmms cleanup In-Reply-To: <20050406163236.GH15748@nostromo.devel.redhat.com> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> Message-ID: <1112805420.10327.92.camel@cutter> On Wed, 2005-04-06 at 12:32 -0400, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > > ? Conflicts < instead of Requires >= > > I just removed the conflict as it seems a bit old, now and added in a > > Requires arts >= 1.3.0 > > This is intentional; it conflicts with older arts, but doesn't > require you to install arts (at least, it shouldn't.) > ah, I see. So for extras for fc4 we shouldn't really need to fret the older conflict, then. B/c if you're on fc4 then you can't be running arts 1.2.0 -sv From rdieter at math.unl.edu Wed Apr 6 16:41:11 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Apr 2005 11:41:11 -0500 Subject: xmms-artsplugin In-Reply-To: <1112805420.10327.92.camel@cutter> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> Message-ID: <42541127.3080305@math.unl.edu> While we're on xmms, IMO, xmms' artsplugin should either: 1. Be packaged separately (preferred) 2. Be a subpackage. -- Rex From thm at duke.edu Wed Apr 6 16:59:17 2005 From: thm at duke.edu (Hunter Matthews) Date: Wed, 06 Apr 2005 12:59:17 -0400 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <42540499.8090408@di.uminho.pt> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> Message-ID: <1112806757.2839.14.camel@jade.biology.duke.edu> On Wed, 2005-04-06 at 11:47, Jos? Pedro Oliveira wrote: > Hunter, > > A couple of notes about the specfiles: > > * License > > License: GPL or Artistic I was unaware perl was dual licensed. Ok - fixing now. > > * URL > > If the module is available in CPAN don't use a URL > that contains the author id and the module version. > > Example: > Use > http://search.cpan.org/dist/Heap/ > instead of > http://search.cpan.org/~jmm/Heap-0.70/ > I was using the urls provided when I searched cpan itself. Is this requirement documented anywhere? > By the way you need to update Heap to version 0.71. > It was current when I started. :) Ok, I'll upgrade it. > * Source tarball URL > > If the module is available in CPAN there is a shorter URL. > > Example: > use > http://www.cpan.org/authors/id/J/JM/JMM/Heap-0.70.tar.gz > instead > http://search.cpan.org/CPAN/authors/id/J/JM/JMM/Heap-0.70.tar.gz > Again, these came from doing a simple cut-n-paste from searching CPAN. Is this other url form requirement documented anywhere? > > * %build section > > When a module is noarch you can drop CFLAGS and OPTIMIZE. > That was just included boilerplate, I'll try to remember to remove it in the future. Fixing. -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From sopwith at redhat.com Wed Apr 6 17:00:00 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 6 Apr 2005 13:00:00 -0400 (EDT) Subject: xmms cleanup In-Reply-To: <1112766155.22212.106.camel@ignacio.ignacio.lan> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> Message-ID: On Wed, 6 Apr 2005, Ignacio Vazquez-Abrams wrote: > - PreReq instead of Requires(pre) I believe Requires(pre) is more correcterer. Just a vague feeling based on what I think jbj said once upon a time. -- Elliot From justin.conover at gmail.com Wed Apr 6 17:36:03 2005 From: justin.conover at gmail.com (Justin Conover) Date: Wed, 6 Apr 2005 12:36:03 -0500 Subject: xmms cleanup In-Reply-To: <1112765374.10327.18.camel@cutter> References: <1112765374.10327.18.camel@cutter> Message-ID: On Apr 6, 2005 12:29 AM, seth vidal wrote: > Hey Folks, > I know I'm not supposed to but I went ahead and built xmms for extras > development in order to get some folks to pipe down. However, I'd like > to go ahead and get a review of this package done. > > spec file is here: > http://cvs.fedora.redhat.com/viewcvs/devel/xmms/xmms.spec?root=extras&rev=1.3&view=auto > > I cleaned up some obvious things and I straightened out the Sources and > Patches so they are sequentially numbered and consistent again. > > Other things I missed? > > Thanks, > -sv > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > Thank you Seth, much appreciated. If I good just figure out how to write patches, specifiacly gcc4 ones than I wouldn't be such a pain in the arse..... :D From skvidal at phy.duke.edu Wed Apr 6 18:17:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 14:17:45 -0400 Subject: xmms-artsplugin In-Reply-To: <42541127.3080305@math.unl.edu> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> Message-ID: <1112811465.10327.99.camel@cutter> On Wed, 2005-04-06 at 11:41 -0500, Rex Dieter wrote: > While we're on xmms, IMO, xmms' artsplugin should either: > 1. Be packaged separately (preferred) > 2. Be a subpackage. > why? -sv From rdieter at math.unl.edu Wed Apr 6 18:26:59 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Apr 2005 13:26:59 -0500 Subject: xmms-artsplugin In-Reply-To: <1112811465.10327.99.camel@cutter> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> <1112811465.10327.99.camel@cutter> Message-ID: <425429F3.30300@math.unl.edu> seth vidal wrote: > On Wed, 2005-04-06 at 11:41 -0500, Rex Dieter wrote: > >>While we're on xmms, IMO, xmms' artsplugin should either: >>1. Be packaged separately (preferred) >>2. Be a subpackage. > why? IMO, 1. It's a separate tarball, it should be a separate package. 2. As is, requires hackery in the xmms specfile to use the just-built, but not-yet installed xmms-devel files. 3. It adds a dependancy on arts, which not all folks want/need (unless it has been upgraded to the artsplugin-0.7.1 that is)... ( and AutoReq: No shouldn't be used either) 4. When/If artsplugin is ever upgraded, won't require a rebuild of the entire xmms. (Most of the same arguments can be made for packaging xmms-skins separately too, especially since it can be .noarch and be shared among all archs). -- Rex From skvidal at phy.duke.edu Wed Apr 6 18:34:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 14:34:09 -0400 Subject: xmms-artsplugin In-Reply-To: <425429F3.30300@math.unl.edu> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> <1112811465.10327.99.camel@cutter> <425429F3.30300@math.unl.edu> Message-ID: <1112812449.10327.106.camel@cutter> > IMO, > 1. It's a separate tarball, it should be a separate package. lots of stuff picks up separate tarballs into one package for user convenience. > 2. As is, requires hackery in the xmms specfile to use the just-built, > but not-yet installed xmms-devel files. true > 3. It adds a dependancy on arts, which not all folks want/need (unless > it has been upgraded to the artsplugin-0.7.1 that is)... ( and AutoReq: > No shouldn't be used either) > 4. When/If artsplugin is ever upgraded, won't require a rebuild of the > entire xmms. I think it's closer to 'if' than 'when' last time I checked xmms devel has halted. > (Most of the same arguments can be made for packaging xmms-skins > separately too, especially since it can be .noarch and be shared among > all archs). If you want to pickup xmms for extras, feel free. I was just building it and patching up the spec file to shut some loud people up. if you'd like to be the owner, it's all yours. -sv From rdieter at math.unl.edu Wed Apr 6 18:46:44 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Apr 2005 13:46:44 -0500 Subject: xmms-artsplugin In-Reply-To: <1112812449.10327.106.camel@cutter> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> <1112811465.10327.99.camel@cutter> <425429F3.30300@math.unl.edu> <1112812449.10327.106.camel@cutter> Message-ID: <42542E94.30001@math.unl.edu> seth vidal wrote: > > > If you want to pickup xmms for extras, feel free. I was just building it > and patching up the spec file to shut some loud people up. > > if you'd like to be the owner, it's all yours. Sure, when/if my month-old cvs access papers ever get processed... -- Rex From skvidal at phy.duke.edu Wed Apr 6 19:10:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 15:10:20 -0400 Subject: xmms-artsplugin In-Reply-To: <42542E94.30001@math.unl.edu> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> <1112811465.10327.99.camel@cutter> <425429F3.30300@math.unl.edu> <1112812449.10327.106.camel@cutter> <42542E94.30001@math.unl.edu> Message-ID: <1112814621.10327.110.camel@cutter> On Wed, 2005-04-06 at 13:46 -0500, Rex Dieter wrote: > seth vidal wrote: > > > > > > > If you want to pickup xmms for extras, feel free. I was just building it > > and patching up the spec file to shut some loud people up. > > > > if you'd like to be the owner, it's all yours. > > Sure, when/if my month-old cvs access papers ever get processed... > who's your sponsor? -sv From rdieter at math.unl.edu Wed Apr 6 19:11:13 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Apr 2005 14:11:13 -0500 Subject: xmms-artsplugin In-Reply-To: <1112814621.10327.110.camel@cutter> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> <1112811465.10327.99.camel@cutter> <425429F3.30300@math.unl.edu> <1112812449.10327.106.camel@cutter> <42542E94.30001@math.unl.edu> <1112814621.10327.110.camel@cutter> Message-ID: <42543451.7010801@math.unl.edu> seth vidal wrote: > On Wed, 2005-04-06 at 13:46 -0500, Rex Dieter wrote: > >>seth vidal wrote: >> >> >>> >>> >>>If you want to pickup xmms for extras, feel free. I was just building it >>>and patching up the spec file to shut some loud people up. >>> >>>if you'd like to be the owner, it's all yours. >> >>Sure, when/if my month-old cvs access papers ever get processed... > who's your sponsor? Elliot Lee -- Rex From skvidal at phy.duke.edu Wed Apr 6 19:29:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 06 Apr 2005 15:29:19 -0400 Subject: xmms-artsplugin In-Reply-To: <42543451.7010801@math.unl.edu> References: <1112765374.10327.18.camel@cutter> <1112766155.22212.106.camel@ignacio.ignacio.lan> <1112767277.10327.24.camel@cutter> <20050406163236.GH15748@nostromo.devel.redhat.com> <1112805420.10327.92.camel@cutter> <42541127.3080305@math.unl.edu> <1112811465.10327.99.camel@cutter> <425429F3.30300@math.unl.edu> <1112812449.10327.106.camel@cutter> <42542E94.30001@math.unl.edu> <1112814621.10327.110.camel@cutter> <42543451.7010801@math.unl.edu> Message-ID: <1112815759.10327.116.camel@cutter> > >>Sure, when/if my month-old cvs access papers ever get processed... > > > who's your sponsor? > > Elliot Lee > okay, I've checked on the account status, we'll get it worked out shortly. sorry. -sv From toshio at tiki-lounge.com Wed Apr 6 19:34:23 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 06 Apr 2005 15:34:23 -0400 Subject: Review needed: notecase In-Reply-To: <1112789435.3405.11.camel@ignacio.ignacio.lan> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> Message-ID: <1112816064.5827.9.camel@Madison.badger.com> Another patch: %changelog * Wed Apr 6 2005 Toshio Kuratomi 0.8.2-4 - Eliminate dos2unix warning by only running on regular files. - Substitute paths in config.h from rpm macros. The first part is trivial. The second part is necessary in order to get help to work. The rest of my notes are at your discretion: * Notemeister is very similar to Notecase and its group is Applications/Productivity. Since Notecase describes itself as an "outliner" I think that would be a more appropriate Group. * Except for prefix, paths in Notecase's build are hardcoded into the Makefile. For example: install -D -m 644 docs/notecase.desktop \ "$(prefix)/share/applications/notecase.desktop"%{ This means %{_bindir}, %{_datadir}, and similar path macros aren't having an effect on where files are installed. So for now, the macros in the %files section and where the files actually end up matches -- but they won't if future versions of Fedora or Notecase change the positions of these directories independently. You may want to note that in the spec or patch the Makefile and submit upstream. This is the reason the second item in my patch operates on both directories listed in config.h even though only one prevents normal operation of the program. -Toshio -- toshio \ Questions for the Would Morticia wear it? @tiki- \ 21st Century! Would it look better on me? lounge.com=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: notecasespec.patch Type: text/x-patch Size: 1358 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 ivazquez at ivazquez.net Wed Apr 6 20:30:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 16:30:38 -0400 Subject: Review needed: notecase In-Reply-To: <1112816064.5827.9.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> Message-ID: <1112819438.3405.28.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 15:34 -0400, Toshio wrote: > Another patch: > %changelog > * Wed Apr 6 2005 Toshio Kuratomi 0.8.2-4 > - Eliminate dos2unix warning by only running on regular files. > - Substitute paths in config.h from rpm macros. > > The first part is trivial. The second part is necessary in order to get > help to work. Works for me. > The rest of my notes are at your discretion: > * Notemeister is very similar to Notecase and its group is > Applications/Productivity. Since Notecase describes itself as an > "outliner" I think that would be a more appropriate Group. Agreed. > * Except for prefix, paths in Notecase's build are hardcoded into the > Makefile. Lovely. Okay, let me look into 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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thm at duke.edu Wed Apr 6 20:31:16 2005 From: thm at duke.edu (Hunter Matthews) Date: Wed, 06 Apr 2005 16:31:16 -0400 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <42540499.8090408@di.uminho.pt> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> Message-ID: <1112819476.2839.23.camel@jade.biology.duke.edu> On Wed, 2005-04-06 at 11:47, Jos? Pedro Oliveira wrote: > Hunter, > > A couple of notes about the specfiles: Ok, I've updated with your suggestions at http://unix-install.biology.duke.edu/linux/biology/distrib/fc-3-devel/i386/ Which is now createrepo optimized. Or enhanced. or something... :) -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From gemi at bluewin.ch Wed Apr 6 20:37:16 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 06 Apr 2005 22:37:16 +0200 Subject: Request for Review: gcl Message-ID: <1112819836.9927.0.camel@scriabin.tannenrauch.ch> http://math.ifi.unizh.ch/fedora/3/i386/SRPMS.gemi/gcl-2.6.6-1.src.rpm GCL is the official Common Lisp for the GNU project. Its design makes use of the system's C compiler to compile to native object code, providing for both good performance and facile portability. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From ivazquez at ivazquez.net Wed Apr 6 22:07:56 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 06 Apr 2005 18:07:56 -0400 Subject: Review needed: notecase In-Reply-To: <1112819438.3405.28.camel@ignacio.ignacio.lan> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> Message-ID: <1112825276.3405.33.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 16:30 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-06 at 15:34 -0400, Toshio wrote: > > * Except for prefix, paths in Notecase's build are hardcoded into the > > Makefile. > > Lovely. Okay, let me look into this. *sigh* "LD=$(CXX) $(DEBUG) $(PROFILE) -L/usr/lib -L/usr/X11R6/lib -ldl -export- dynamic" How would I handle this for 64-bit builds? "make LD=... -L%{_prefix}/X11R6/%{_lib} ..." in the spec 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 bugs.michael at gmx.net Wed Apr 6 22:38:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Apr 2005 00:38:55 +0200 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <1112797177.10327.65.camel@cutter> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> Message-ID: <20050407003855.5fc2a195.bugs.michael@gmx.net> On Wed, 06 Apr 2005 10:19:37 -0400, seth vidal wrote: > > > I could create a list with the names of all bumped packages (and > > optionally an exclude list of all packages not touched). > > That'd be cool. I was just going to do a regex from my commits > mailbox. :) Release bump done. Tagging still in process, though (takes a lot more time and is not so important, but well, now that I started it...;). Two package lists attached: (1) packages-list.txt : all CVS module names where release was bumped (2) packages-exclude-list.txt : all modules _not_ touched -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: packages-list.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: packages-exclude-list.txt URL: From bugs.michael at gmx.net Wed Apr 6 22:58:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Apr 2005 00:58:53 +0200 Subject: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <1112797177.10327.65.camel@cutter> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> Message-ID: <20050407005853.62eeec01.bugs.michael@gmx.net> Before somebody notices and complains: yes, the inserted extra blank line after every "Release" tag is unintended. And April 7th is a Thursday, not a Friday (the effect of hacking in a localtime-dependent %changelog entry in the last minute). Purely cosmetic. Sorry. From jpo at di.uminho.pt Thu Apr 7 00:49:56 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 07 Apr 2005 01:49:56 +0100 Subject: Request for review: tetex-perltex (2) Message-ID: <425483B4.8060906@di.uminho.pt> Summary: Define LaTeX macros in terms of Perl code URL: http://www.ctan.org/tex-archive/help/Catalogue/entries/perltex.html Description: PerlTeX is a combination Perl script (perltex) and LaTeX2e style file (perltex.sty) that, together, give the user the ability to define LaTeX macros in terms of Perl code. Once defined, a Perl macro becomes indistinguishable from any other LaTeX macro. PerlTeX thereby combines LaTeX's typesetting power with Perl's programmability. Signed SRPM: http://gsd.di.uminho.pt/jpo/software/fedora/tetex-perltex-1.2-1.src.rpm Specfile: http://gsd.di.uminho.pt/jpo/software/fedora/tetex-perltex.spec -- 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 * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From toshio at tiki-lounge.com Thu Apr 7 01:56:55 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 06 Apr 2005 21:56:55 -0400 Subject: Review needed: notecase In-Reply-To: <1112825276.3405.33.camel@ignacio.ignacio.lan> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> <1112825276.3405.33.camel@ignacio.ignacio.lan> Message-ID: <1112839017.8621.11.camel@Madison.badger.com> On Wed, 2005-04-06 at 18:07 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-06 at 16:30 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-04-06 at 15:34 -0400, Toshio wrote: > > > * Except for prefix, paths in Notecase's build are hardcoded into the > > > Makefile. > > > > Lovely. Okay, let me look into this. > > *sigh* > > "LD=$(CXX) $(DEBUG) $(PROFILE) -L/usr/lib -L/usr/X11R6/lib -ldl -export- > dynamic" > > How would I handle this for 64-bit builds? "make LD=... > -L%{_prefix}/X11R6/%{_lib} ..." in the spec file? > I'm very tired from not having slept enough yesterday so I could have missed something important, but I just test built the srpm from CVS on an FC3 x86_64 box and it went smoothly. ldd of the resulting binary shows that notecase successfully linked against the /usr/lib64/ versions of libraries. My guess is that the gcc toolchain knows to search /usr/lib64 and /usr/X11R6/lib64 for libraries and it pulled things in automatically (Maybe with some help from the gtk pkg-config flags.) I noticed several gcc warnings that I think can be fixed by changing int/unsigned int's into long/unsigned long's. Too tired to test changes ATM, but some of them do look to need fixing in order to make notecase run correctly on 64 bit. -Toshio -- toshio \ "A lasting friendship is one where you never expect anything, @tiki \ always working to make the friendship better. A good friendship -lounge \ is one where the other person does the same." .com \____________________________________________________ GA->ME 1999 -------------- 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 Apr 7 04:38:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Apr 2005 00:38:07 -0400 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <20050407003855.5fc2a195.bugs.michael@gmx.net> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> <20050407003855.5fc2a195.bugs.michael@gmx.net> Message-ID: <1112848688.10327.163.camel@cutter> > Release bump done. Tagging still in process, though (takes a lot more > time and is not so important, but well, now that I started it...;). > > Two package lists attached: > > (1) packages-list.txt : all CVS module names where release was bumped > (2) packages-exclude-list.txt : all modules _not_ touched I pruned: python-twisted - in core python-numeric - in core python-sqlite - in core sqlite - in core and then I kicked off the mass rebuild on i386 and x86_64 I'm going to let it cycle a few times as some dep errors will occur if things aren't built in the right order. I would fully expect for there to be A LOT of build failures due to gcc4 and friends. While that is running I'll continue working on the automation mechanisms so I don't ever have to do this again! :) -sv From rc040203 at freenet.de Thu Apr 7 05:08:29 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 07 Apr 2005 07:08:29 +0200 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <1112806757.2839.14.camel@jade.biology.duke.edu> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> <1112806757.2839.14.camel@jade.biology.duke.edu> Message-ID: <1112850509.20996.187.camel@mccallum.corsepiu.local> On Wed, 2005-04-06 at 12:59 -0400, Hunter Matthews wrote: > On Wed, 2005-04-06 at 11:47, Jos? Pedro Oliveira wrote: > > Hunter, > > > > A couple of notes about the specfiles: > > > > * License > > > > License: GPL or Artistic > > I was unaware perl was dual licensed. Ok - fixing now. Well, Perl is dual licensed, but individual modules aren't necessarily. Some of them are pure GPL, some of them are pure Artistic and some of them come under other licenses. In theory you'll have to look up each module's licensing anew. > > > > * URL > > > > If the module is available in CPAN don't use a URL > > that contains the author id and the module version. > > > > Example: > > Use > > http://search.cpan.org/dist/Heap/ > > instead of > > http://search.cpan.org/~jmm/Heap-0.70/ > > > I was using the urls provided when I searched cpan itself. > > Is this requirement documented anywhere? I am not aware about such a requirement. But even if, this should be reconsidered. > > * Source tarball URL > > > > If the module is available in CPAN there is a shorter URL. > > > > Example: > > use > > http://www.cpan.org/authors/id/J/JM/JMM/Heap-0.70.tar.gz > > instead > > http://search.cpan.org/CPAN/authors/id/J/JM/JMM/Heap-0.70.tar.gz > > > > Again, these came from doing a simple cut-n-paste from searching > CPAN. > > Is this other url form requirement documented anywhere? I am not aware about such a requirement. But even if, this should be reconsidered. Ralf From adrian at lisas.de Thu Apr 7 05:56:23 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 7 Apr 2005 07:56:23 +0200 Subject: Jabber Server? In-Reply-To: References: <20050307202220.GA681@osiris.silug.org> <20050309080911.GA7375@lisas.de> <87d5u99ish.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050310071622.GA30432@lisas.de> <20050319113329.GA18736@lisas.de> <873bul41nn.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050329145542.GA21755@lisas.de> <20050329173513.GA28194@lisas.de> Message-ID: <20050407055623.GA2277@lisas.de> On Tue, Mar 29, 2005 at 10:45:56PM -0600, Jason L Tibbitts III wrote: > >>>>> "AR" == Adrian Reber writes: > > AR> Reading the configuration files I would say that it can use > AR> saslauthd. > > So let saslauthd handle your PAM authentication. Then jabberd can run > as any user and still authenticate against the hidden system > databases. Thanks. Didn't even think about this option... Although I have already used saslauthd. Adrian -- Adrian Reber http://lisas.de/~adrian/ The next person to mention spaghetti stacks to me is going to have his head knocked off. -- Bill Conrad From adrian at lisas.de Thu Apr 7 06:15:50 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 7 Apr 2005 08:15:50 +0200 Subject: Jabber Server? In-Reply-To: <20050329172738.GA19785@lisas.de> References: <20050307180250.GA2630@lisas.de> <20050307202220.GA681@osiris.silug.org> <20050309080911.GA7375@lisas.de> <87d5u99ish.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050310071622.GA30432@lisas.de> <20050319113329.GA18736@lisas.de> <873bul41nn.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050329145542.GA21755@lisas.de> <871x9ya2er.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050329172738.GA19785@lisas.de> Message-ID: <20050407061550.GA6467@lisas.de> On Tue, Mar 29, 2005 at 07:27:38PM +0200, Adrian Reber wrote: > This would be no problem. I just thought that I can add another option > to sysconfig/jabberd which toggles if c2s should be started as root or > as the jabber user. Default would be to start it as jabber and if it is > required (as in my case) it would be necessary to change it in this > file. Would this be an acceptable solution? I have now checked in a version with this behaviour. Is this better or should I just drop the whole thing and just use saslauthd. What I like about the current solution is that I jabberd can be installed and it works without the need to change anything if pam without shadow is used. If pam with shadow is used it is necessary to change a line in sysconfig/jabberd and it should work. If any other authentication mechanisms is desired the user has to configure something of course but to get a working jabberd it is just install it and you're done. Adrian -- Adrian Reber http://lisas.de/~adrian/ Steinbach's Guideline for Systems Programming: Never test for an error condition you don't know how to handle. From dwmw2 at infradead.org Thu Apr 7 07:06:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 07 Apr 2005 08:06:17 +0100 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <1112848688.10327.163.camel@cutter> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> <20050407003855.5fc2a195.bugs.michael@gmx.net> <1112848688.10327.163.camel@cutter> Message-ID: <1112857579.6924.13.camel@localhost.localdomain> On Thu, 2005-04-07 at 00:38 -0400, seth vidal wrote: > I pruned: > python-twisted - in core > python-numeric - in core > python-sqlite - in core > sqlite - in core gnome-cpufreq-applet is in core too, as part of gnome-applets. -- dwmw2 From ivazquez at ivazquez.net Thu Apr 7 07:33:15 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 03:33:15 -0400 Subject: Review needed: notecase In-Reply-To: <1112839017.8621.11.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> <1112825276.3405.33.camel@ignacio.ignacio.lan> <1112839017.8621.11.camel@Madison.badger.com> Message-ID: <1112859195.3405.35.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 21:56 -0400, Toshio wrote: > On Wed, 2005-04-06 at 18:07 -0400, Ignacio Vazquez-Abrams wrote: > > *sigh* > > > > "LD=$(CXX) $(DEBUG) $(PROFILE) -L/usr/lib -L/usr/X11R6/lib -ldl -export- > > dynamic" > > > > How would I handle this for 64-bit builds? "make LD=... > > -L%{_prefix}/X11R6/%{_lib} ..." in the spec file? > > > I'm very tired from not having slept enough yesterday so I could have > missed something important, but I just test built the srpm from CVS on > an FC3 x86_64 box and it went smoothly. ldd of the resulting binary > shows that notecase successfully linked against the /usr/lib64/ versions > of libraries. My guess is that the gcc toolchain knows to > search /usr/lib64 and /usr/X11R6/lib64 for libraries and it pulled > things in automatically (Maybe with some help from the gtk pkg-config > flags.) Yeah, but I figure I'm better safe then sorry. > I noticed several gcc warnings that I think can be fixed by changing > int/unsigned int's into long/unsigned long's. Too tired to test changes > ATM, but some of them do look to need fixing in order to make notecase > run correctly on 64 bit. I really need to get access to an x86_64 box so I can test this stuff myself. Any takers? -- 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 Apr 7 10:09:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Apr 2005 12:09:44 +0200 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <1112850509.20996.187.camel@mccallum.corsepiu.local> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> <1112806757.2839.14.camel@jade.biology.duke.edu> <1112850509.20996.187.camel@mccallum.corsepiu.local> Message-ID: <20050407120944.3b048803.bugs.michael@gmx.net> On Thu, 07 Apr 2005 07:08:29 +0200, Ralf Corsepius wrote: > > > > > > * URL > > > > > > If the module is available in CPAN don't use a URL > > > that contains the author id and the module version. > > > > > > Example: > > > Use > > > http://search.cpan.org/dist/Heap/ > > > instead of > > > http://search.cpan.org/~jmm/Heap-0.70/ > > > > > I was using the urls provided when I searched cpan itself. > > > > Is this requirement documented anywhere? > > I am not aware about such a requirement. But even if, this should be > reconsidered. There is no such requirement. This shows that even without a "QA checklist" different reviewers suggest different changes based on personal preference, aesthetics or special expertise. And I'm afraid, that won't change ever. Unless we return to fedora.us style of marking items as "blockers" and "non-blockers" (or "suggestions"/"hints", respectively). > > > * Source tarball URL > > > > > > If the module is available in CPAN there is a shorter URL. > > > > > > Example: > > > use > > > http://www.cpan.org/authors/id/J/JM/JMM/Heap-0.70.tar.gz > > > instead > > > http://search.cpan.org/CPAN/authors/id/J/JM/JMM/Heap-0.70.tar.gz > > > > > > > Again, these came from doing a simple cut-n-paste from searching > > CPAN. > > > > Is this other url form requirement documented anywhere? > > I am not aware about such a requirement. But even if, this should be > reconsidered. Same as above. From bugs.michael at gmx.net Thu Apr 7 10:29:11 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Apr 2005 12:29:11 +0200 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <1112848688.10327.163.camel@cutter> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> <20050407003855.5fc2a195.bugs.michael@gmx.net> <1112848688.10327.163.camel@cutter> Message-ID: <20050407122911.48a7098f.bugs.michael@gmx.net> On Thu, 07 Apr 2005 00:38:07 -0400, seth vidal wrote: > I would fully expect for there to be A LOT of build failures due to gcc4 > and friends. > > While that is running I'll continue working on the automation mechanisms > so I don't ever have to do this again! :) Right. With tag based build requests and an automated build system, it should become more convenient to rebuild specific packages when necessary, so e.g. C++/Python ABI changes don't block anything. But for the future we need a roadmad/schedule and try something with deadlines anyway, so package owners trigger necessary rebuilds in time, and true noarch [data/doc] packages only get rebuilt when needed. For FC-4 we're still not complete with regard to current package owners. Some are waiting for CVS access, a few for sponsorship, and a very few have not reacted on notifications and not added themselves to the Wiki page yet. For FC-5 I assume it would be even less feasible to do such a pretty braindead release bump, so assume this is the last time it's done. :) From ivazquez at ivazquez.net Thu Apr 7 10:49:17 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 06:49:17 -0400 Subject: Request for Review: gcl In-Reply-To: <1112819836.9927.0.camel@scriabin.tannenrauch.ch> References: <1112819836.9927.0.camel@scriabin.tannenrauch.ch> Message-ID: <1112870957.3405.44.camel@ignacio.ignacio.lan> On Wed, 2005-04-06 at 22:37 +0200, G?rard Milmeister wrote: > http://math.ifi.unizh.ch/fedora/3/i386/SRPMS.gemi/gcl-2.6.6-1.src.rpm > > GCL is the official Common Lisp for the GNU project. Its design makes > use of the system's C compiler to compile to native object code, > providing for both good performance and facile portability. Looks okay. It might be nice to have the HTML, man, and doc/* stuff included, but it's hardly necessary. Also, I didn't see anything in %{_datadir}/emacs, and %configure should use macros provided any path at all is actually required. Bring it in and fix it up. -- 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 Thu Apr 7 10:49:21 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 06:49:21 -0400 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack Message-ID: <1112870961.3405.46.camel@ignacio.ignacio.lan> gnome-theme-clearlooks-bigpack: Additional Clearlooks color schemes Lots and lots of color schemes for the Clearlooks GTK+ 2.x engine. I said it, I did it. I'll bifurcate the Requires and activate the disttag in CVS. And yes, the tarball on this one is a bit screwy as well. I seriously would like to know what version of tar produces these. -- 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 Thu Apr 7 10:51:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 06:51:35 -0400 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack In-Reply-To: <1112870961.3405.46.camel@ignacio.ignacio.lan> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> Message-ID: <1112871095.3405.47.camel@ignacio.ignacio.lan> On Thu, 2005-04-07 at 06:49 -0400, Ignacio Vazquez-Abrams wrote: > gnome-theme-clearlooks-bigpack: Additional Clearlooks color schemes > > Lots and lots of color schemes for the Clearlooks GTK+ 2.x engine. > > I said it, I did it. I'll bifurcate the Requires and activate the > disttag in CVS. And yes, the tarball on this one is a bit screwy as > well. I seriously would like to know what version of tar produces these. *sigh* I think I need some sleep soon. http://fedora.ivazquez.net/files/gnome-theme-clearlooks- bigpack-0.5-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 wtogami at redhat.com Thu Apr 7 11:09:49 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Apr 2005 01:09:49 -1000 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack In-Reply-To: <1112870961.3405.46.camel@ignacio.ignacio.lan> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> Message-ID: <425514FD.1000703@redhat.com> %if "%fedora" > "3" Requires: gtk2-engines %else Requires: gnome-theme-clearlooks %endif Where is this %fedora macro coming from? Even if %fedora is defined somewhere, what kind of comparison happens there? String compare? Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Thu Apr 7 11:16:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 07:16:16 -0400 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack In-Reply-To: <425514FD.1000703@redhat.com> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> Message-ID: <1112872576.3405.55.camel@ignacio.ignacio.lan> On Thu, 2005-04-07 at 01:09 -1000, Warren Togami wrote: > %if "%fedora" > "3" > Requires: gtk2-engines > %else > Requires: gnome-theme-clearlooks > %endif > > Where is this %fedora macro coming from? > Even if %fedora is defined somewhere, what kind of comparison happens > there? String compare? It's part of the disttag set. http://www.fedoraproject.org/wiki/DistTag And yes, it's a string compare. As I mentioned, I'll split it in CVS. -- 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 Apr 7 11:31:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Apr 2005 07:31:23 -0400 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <20050407122911.48a7098f.bugs.michael@gmx.net> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> <20050407003855.5fc2a195.bugs.michael@gmx.net> <1112848688.10327.163.camel@cutter> <20050407122911.48a7098f.bugs.michael@gmx.net> Message-ID: <1112873483.10327.179.camel@cutter> > Right. With tag based build requests and an automated build system, it > should become more convenient to rebuild specific packages when necessary, > so e.g. C++/Python ABI changes don't block anything. But for the future we > need a roadmad/schedule and try something with deadlines anyway, so > package owners trigger necessary rebuilds in time, and true noarch > [data/doc] packages only get rebuilt when needed. For FC-4 we're still not > complete with regard to current package owners. Some are waiting for CVS > access, a few for sponsorship, and a very few have not reacted on > notifications and not added themselves to the Wiki page yet. For FC-5 I > assume it would be even less feasible to do such a pretty braindead > release bump, so assume this is the last time it's done. :) the current plan for the buildsystem is: make tag make build this will mark a 'tobuild' file in common and the build system will query that file on a regular basis and build whatever is in there. right now the querying and srpm generation via this system is done, I'm trying to make sure we get good results as to what failures hold a package back. -sv From wtogami at redhat.com Thu Apr 7 11:40:55 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Apr 2005 01:40:55 -1000 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack In-Reply-To: <1112872576.3405.55.camel@ignacio.ignacio.lan> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> <1112872576.3405.55.camel@ignacio.ignacio.lan> Message-ID: <42551C47.5020506@redhat.com> Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-07 at 01:09 -1000, Warren Togami wrote: > >>%if "%fedora" > "3" >>Requires: gtk2-engines >>%else >>Requires: gnome-theme-clearlooks >>%endif >> >>Where is this %fedora macro coming from? >>Even if %fedora is defined somewhere, what kind of comparison happens >>there? String compare? > Is it safe to rely on this when %fedora will only be defined on FC4+? And will string compare continue working properly with all possible numbers? > > It's part of the disttag set. > > http://www.fedoraproject.org/wiki/DistTag Keep in mind that the proposal on this page has not been ratified, and has even been largely rewritten because this macro-based approach is extremely problematic. See the newer proposal on fedora-packaging list. Warren Togami wtogami at redhat.com From fedora at camperquake.de Thu Apr 7 11:50:44 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 7 Apr 2005 13:50:44 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050406114616.4b0fcd71.bugs.michael@gmx.net> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <1112731904.22212.83.camel@ignacio.ignacio.lan> <20050405232827.11b19e26.bugs.michael@gmx.net> <1112756982.22212.85.camel@ignacio.ignacio.lan> <20050406114616.4b0fcd71.bugs.michael@gmx.net> Message-ID: <20050407135044.452b0138@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > A lot of what you see on the "Packaging Guidelines" page in the wiki has > been copied from fedora.us guidelines. In this particular case, the > PackagingHints page: http://www.fedora.us/wiki/PackagingHints#macros > > That section is misleading and not a package quality criterion. > Fedora.us has had different requirements. Since I personally like macros in source: lines, I will import the -1 package, which still has those. -- Men are like snowstorms: You never know when he's coming, how many inches you'll get, or how long it will last. From ivazquez at ivazquez.net Thu Apr 7 11:53:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 07:53:09 -0400 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack In-Reply-To: <42551C47.5020506@redhat.com> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> <1112872576.3405.55.camel@ignacio.ignacio.lan> <42551C47.5020506@redhat.com> Message-ID: <1112874789.3405.61.camel@ignacio.ignacio.lan> On Thu, 2005-04-07 at 01:40 -1000, Warren Togami wrote: > Is it safe to rely on this when %fedora will only be defined on FC4+? > And will string compare continue working properly with all possible numbers? In reality this whole issue/argument/discussion is moot. I only have that in there to remind myself that I need to split it when there's a FC-3 branch for it. As soon as that shows up I'm going to diverge the 2 branches to only have the appropriate Requires. -- 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 wtogami at redhat.com Thu Apr 7 11:55:32 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Apr 2005 01:55:32 -1000 Subject: Request for sponsor: gnome-theme-clearlooks-bigpack In-Reply-To: <1112874789.3405.61.camel@ignacio.ignacio.lan> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> <1112872576.3405.55.camel@ignacio.ignacio.lan> <42551C47.5020506@redhat.com> <1112874789.3405.61.camel@ignacio.ignacio.lan> Message-ID: <42551FB4.5090000@redhat.com> Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-07 at 01:40 -1000, Warren Togami wrote: > >>Is it safe to rely on this when %fedora will only be defined on FC4+? >>And will string compare continue working properly with all possible numbers? > > > In reality this whole issue/argument/discussion is moot. I only have > that in there to remind myself that I need to split it when there's a > FC-3 branch for it. As soon as that shows up I'm going to diverge the 2 > branches to only have the appropriate Requires. > OK then the package is fine. Go ahead and post APPROVED. Warren From rdieter at math.unl.edu Thu Apr 7 12:07:35 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Apr 2005 07:07:35 -0500 Subject: dist tag usage In-Reply-To: <1112872576.3405.55.camel@ignacio.ignacio.lan> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> <1112872576.3405.55.camel@ignacio.ignacio.lan> Message-ID: <42552287.1040500@math.unl.edu> Ignacio Vazquez-Abrams wrote: > It's part of the disttag set. > > http://www.fedoraproject.org/wiki/DistTag Here's a suggestion for that page: Replace %{?dist:%{dist}} references with %{?dist} (It's shorter and produces the same result). -- Rex From wtogami at redhat.com Thu Apr 7 12:11:38 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Apr 2005 02:11:38 -1000 Subject: dist tag usage In-Reply-To: <42552287.1040500@math.unl.edu> References: <1112870961.3405.46.camel@ignacio.ignacio.lan> <425514FD.1000703@redhat.com> <1112872576.3405.55.camel@ignacio.ignacio.lan> <42552287.1040500@math.unl.edu> Message-ID: <4255237A.3060508@redhat.com> Rex Dieter wrote: > Ignacio Vazquez-Abrams wrote: > >> It's part of the disttag set. >> >> http://www.fedoraproject.org/wiki/DistTag > > > Here's a suggestion for that page: > > Replace %{?dist:%{dist}} references with %{?dist} > (It's shorter and produces the same result). > Please discuss this on fedora-packaging list. From fedora at camperquake.de Thu Apr 7 13:08:22 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 7 Apr 2005 15:08:22 +0200 Subject: Request for Review: enemies-of-carlotta In-Reply-To: <20050407135044.452b0138@nausicaa.camperquake.de> References: <20050405212132.34f32e43@nausicaa.camperquake.de> <1112731904.22212.83.camel@ignacio.ignacio.lan> <20050405232827.11b19e26.bugs.michael@gmx.net> <1112756982.22212.85.camel@ignacio.ignacio.lan> <20050406114616.4b0fcd71.bugs.michael@gmx.net> <20050407135044.452b0138@nausicaa.camperquake.de> Message-ID: <20050407150822.5f84efe8@nausicaa.camperquake.de> Hi. Ralf Ertzinger wrote: > Since I personally like macros in source: lines, I will import the -1 > package, which still has those. Import is done. Are there still comments on the package, or may I send an APPROVED for it? -- Tiritonga, tiritonga From rc040203 at freenet.de Thu Apr 7 16:15:32 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 07 Apr 2005 18:15:32 +0200 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <20050407120944.3b048803.bugs.michael@gmx.net> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> <1112806757.2839.14.camel@jade.biology.duke.edu> <1112850509.20996.187.camel@mccallum.corsepiu.local> <20050407120944.3b048803.bugs.michael@gmx.net> Message-ID: <1112890532.20996.190.camel@mccallum.corsepiu.local> On Thu, 2005-04-07 at 12:09 +0200, Michael Schwendt wrote: > On Thu, 07 Apr 2005 07:08:29 +0200, Ralf Corsepius wrote: > > > > > > > > > * URL > > > > > > > > If the module is available in CPAN don't use a URL > > > > that contains the author id and the module version. > > > > > > > > Example: > > > > Use > > > > http://search.cpan.org/dist/Heap/ > > > > instead of > > > > http://search.cpan.org/~jmm/Heap-0.70/ > > > > > > > I was using the urls provided when I searched cpan itself. > > > > > > Is this requirement documented anywhere? > > > > I am not aware about such a requirement. But even if, this should be > > reconsidered. > > There is no such requirement. Glad to hear this. > This shows that even without a "QA checklist" different reviewers suggest > different changes based on personal preference, aesthetics or special > expertise. And I'm afraid, that won't change ever. Unless we return to > fedora.us style of marking items as "blockers" and "non-blockers" (or > "suggestions"/"hints", respectively). IMO, the only thing that matter wrt. "URL:" and "Source:"-tag's is them being valid ;) Ralf From Jochen at herr-schmitt.de Thu Apr 7 17:19:27 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 07 Apr 2005 19:19:27 +0200 Subject: Request for Preview: INADYN Message-ID: http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-0.2.src.rpm is a lightwight DynDNS client wrttien in puer C. Best Regards: From mricon at gmail.com Thu Apr 7 17:56:31 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 7 Apr 2005 13:56:31 -0400 Subject: Review: Epylog In-Reply-To: <1112478752.9017.2.camel@cutter> References: <1112478752.9017.2.camel@cutter> Message-ID: Hello, all: If there are no further objections, I'm going to go ahead and mark epylog as approved with Seth Vidal and Jeff Sheltren as reviewers. Cheers, -- Konstantin Ryabitsev Zlotniks, INC From skvidal at phy.duke.edu Thu Apr 7 17:56:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Apr 2005 13:56:02 -0400 Subject: Review: Epylog In-Reply-To: References: <1112478752.9017.2.camel@cutter> Message-ID: <1112896562.20535.10.camel@cutter> On Thu, 2005-04-07 at 13:56 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > If there are no further objections, I'm going to go ahead and mark > epylog as approved with Seth Vidal and Jeff Sheltren as reviewers. Approved. -sv From gemi at bluewin.ch Thu Apr 7 18:11:23 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 07 Apr 2005 20:11:23 +0200 Subject: Request for Review: gcl In-Reply-To: <1112870957.3405.44.camel@ignacio.ignacio.lan> References: <1112819836.9927.0.camel@scriabin.tannenrauch.ch> <1112870957.3405.44.camel@ignacio.ignacio.lan> Message-ID: <1112897483.28152.3.camel@scriabin.tannenrauch.ch> On Thu, 2005-04-07 at 06:49 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-06 at 22:37 +0200, G?rard Milmeister wrote: > > http://math.ifi.unizh.ch/fedora/3/i386/SRPMS.gemi/gcl-2.6.6-1.src.rpm > > > > GCL is the official Common Lisp for the GNU project. Its design makes > > use of the system's C compiler to compile to native object code, > > providing for both good performance and facile portability. I just imported the package. > Looks okay. It might be nice to have the HTML, man, and doc/* stuff > included, but it's hardly necessary. The html docs and man page are now included. > Also, I didn't see anything in > %{_datadir}/emacs, Emacs files (not xemacs) are included. I doubt however if they are useful since they quite old. It is possibly better to leave them out entirely and make a package for the slime emacs package. > and %configure should use macros provided any path at > all is actually required. The configure parameters were wrong anyway, I have corrected them, they use macros now. AFAICT tk works. > Bring it in and fix it up. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From Jochen at herr-schmitt.de Thu Apr 7 18:27:16 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 07 Apr 2005 20:27:16 +0200 Subject: Request for Review: INADYN [Was: Re: Request for Preview: INADYN] In-Reply-To: References: Message-ID: On Thu, 07 Apr 2005 19:19:27 +0200, you wrote: >http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-0.2.src.rpm > >is a lightwight DynDNS client wrttien in puer C. > >Best Regards: Sorry for the typo in the subject. Best Regards: Jochen Schmitt From tcallawa at redhat.com Thu Apr 7 19:06:11 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 07 Apr 2005 14:06:11 -0500 Subject: Suggestion for standardization Message-ID: <1112900771.3808.50.camel@localhost.localdomain> The package review process is utterly confusing to me, so it can't make much more sense to everyone else. I propose that we adopt an "ACK" style system, where trusted contributors can ACK a package on review, two ACKs (maybe three?) will mark it as approved/sponsored. The trusted contributor providing the second ACK closes the bugzilla. This presumes that the person submitting new packages for review is already listed as a Contributor with CVS access. If a trusted contributor "NACK"s a package, they have to provide a reason, and the package cannot be submitted to CVS until the problem causing the NACK is lifted, or the trusted contributor withdraws the NACK. Ideally, I'd like to do this in bugzilla.redhat.com. Perhaps we can create a fedora-extras-QA component, and have new packages for review be assigned to that. This component would go to all trusted contributors (and/or fedora-extras-list) by default. As is now, we're losing track of packages, no one knows when a review is sufficient. The old bugzilla fedora.us system worked well for this, and I don't see any reason why it shouldn't be adapted for FE. The Red Hat folks should already be comfortable with the ACK system, so it gives the best of both worlds. I think assigning the "QA" group to the trusted contributors maps well to the added responsibility of that role. If you're willing to sponsor people, then you should be willing to QA new packages. What do you think? If people like the idea, I could document it this weekend, and we can start following 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 ivazquez at ivazquez.net Thu Apr 7 20:37:07 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 16:37:07 -0400 Subject: Request for Preview: INADYN In-Reply-To: References: Message-ID: <1112906227.3405.81.camel@ignacio.ignacio.lan> On Thu, 2005-04-07 at 19:19 +0200, Jochen Schmitt wrote: > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-0.2.src.rpm > > is a lightwight DynDNS client wrttien in puer C. ? Name and version macros at the top ? Incorrect release number - Superflous Epoch 0 - Summary contains the package name - What happened to %setup? - Doesn't remove the buildroot at the beginning of %install - No modes on install - Doesn't use macros throughout %install - Don't create %{_docdir} manually - No changelog Corrected spec file is attached. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- Name: inadyn Version: 1.90 Release: 1 Summary: A Dynamic DNS Client. Group: System Environment/Daemons License: GPL URL: http://inadyn.ina-tech.net Source0: inadyn.v%{version}.zip Source1: inadyn.conf BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %description INADYN is a dynamic DNS client. It maintains the IP address of a host name. It periodically checks wheather the IP address stored by the DSN server is the real current address of the machine that is running INADYN. %prep %setup -q -c %build make -f makefile.linux %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_sbindir} install -m 0755 bin/inadyn $RPM_BUILD_ROOT%{_sbindir} mkdir -p $RPM_BUILD_ROOT%{_mandir}/man5 mkdir -p $RPM_BUILD_ROOT%{_mandir}/man8 install -m 0644 man/inadyn.8 $RPM_BUILD_ROOT%{_mandir}/man8 install -m 0644 man/inadyn.conf.5 $RPM_BUILD_ROOT%{_mandir}/man5 mkdir -p $RPM_BUILD_ROOT%{_sysconfdir} install -p -m 0600 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir} %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc readme.html %{_sbindir}/inadyn %{_mandir}/man*/* %config /etc/inadyn.conf %changelog * Thu Apr 7 2005 Jochen Schmitt 1.9.0-1 - Initial RPM release -------------- 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 Lam at Lam.pl Thu Apr 7 21:31:30 2005 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 07 Apr 2005 23:31:30 +0200 Subject: ppracer In-Reply-To: <1110302494.14945.41.camel@wombat.tiptoe.de> References: <20050304185533.0f86d703@python2> <1109963985.6560.1.camel@gibraltar.stuttgart.redhat.com> <20050304200524.2ab07345@python2> <1109967124.6560.16.camel@gibraltar.stuttgart.redhat.com> <20050304214209.GA15879@lisas.de> <1110203566.32665.1.camel@wombat.tiptoe.de> <20050307174856.GA24061@lisas.de> <1110289850.14945.12.camel@wombat.tiptoe.de> <20050308143823.GA21446@lisas.de> <1110298765.14945.20.camel@wombat.tiptoe.de> <20050308163446.GB4066@lisas.de> <1110302494.14945.41.camel@wombat.tiptoe.de> Message-ID: <1112909490.6071.13.camel@pensja.lam.pl> Is it just my apt, or is ppracer still absent from FE? Sorry for interruption and all, but I'm waiting for it :) Lam From ivazquez at ivazquez.net Thu Apr 7 21:43:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 07 Apr 2005 17:43:26 -0400 Subject: ppracer In-Reply-To: <1112909490.6071.13.camel@pensja.lam.pl> References: <20050304185533.0f86d703@python2> <1109963985.6560.1.camel@gibraltar.stuttgart.redhat.com> <20050304200524.2ab07345@python2> <1109967124.6560.16.camel@gibraltar.stuttgart.redhat.com> <20050304214209.GA15879@lisas.de> <1110203566.32665.1.camel@wombat.tiptoe.de> <20050307174856.GA24061@lisas.de> <1110289850.14945.12.camel@wombat.tiptoe.de> <20050308143823.GA21446@lisas.de> <1110298765.14945.20.camel@wombat.tiptoe.de> <20050308163446.GB4066@lisas.de> <1110302494.14945.41.camel@wombat.tiptoe.de> <1112909490.6071.13.camel@pensja.lam.pl> Message-ID: <1112910206.3405.83.camel@ignacio.ignacio.lan> On Thu, 2005-04-07 at 23:31 +0200, Leszek Matok wrote: > Is it just my apt, or is ppracer still absent from FE? Sorry for > interruption and all, but I'm waiting for it :) Feel free to pull it from CVS and build it. http://cvs.fedora.redhat.com/extras.shtml -- 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 Apr 7 21:39:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Apr 2005 17:39:26 -0400 Subject: ppracer In-Reply-To: <1112909490.6071.13.camel@pensja.lam.pl> References: <20050304185533.0f86d703@python2> <1109963985.6560.1.camel@gibraltar.stuttgart.redhat.com> <20050304200524.2ab07345@python2> <1109967124.6560.16.camel@gibraltar.stuttgart.redhat.com> <20050304214209.GA15879@lisas.de> <1110203566.32665.1.camel@wombat.tiptoe.de> <20050307174856.GA24061@lisas.de> <1110289850.14945.12.camel@wombat.tiptoe.de> <20050308143823.GA21446@lisas.de> <1110298765.14945.20.camel@wombat.tiptoe.de> <20050308163446.GB4066@lisas.de> <1110302494.14945.41.camel@wombat.tiptoe.de> <1112909490.6071.13.camel@pensja.lam.pl> Message-ID: <1112909966.20535.20.camel@cutter> On Thu, 2005-04-07 at 23:31 +0200, Leszek Matok wrote: > Is it just my apt, or is ppracer still absent from FE? Sorry for > interruption and all, but I'm waiting for it :) > It's in fedora extras development but not in fe3 b/c it obsoletes tuxracer - which comes with fc3. -s From wtogami at redhat.com Thu Apr 7 22:05:48 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Apr 2005 12:05:48 -1000 Subject: Suggestion for standardization In-Reply-To: <1112900771.3808.50.camel@localhost.localdomain> References: <1112900771.3808.50.camel@localhost.localdomain> Message-ID: <4255AEBC.1080102@redhat.com> Tom 'spot' Callaway wrote: > The package review process is utterly confusing to me, so it can't make > much more sense to everyone else. > > I propose that we adopt an "ACK" style system, where trusted > contributors can ACK a package on review, two ACKs (maybe three?) will > mark it as approved/sponsored. The trusted contributor providing the > second ACK closes the bugzilla. This is trying to solve the wrong problem. The process is confusing not because of the requirements but because of the lack of tracking. > > This presumes that the person submitting new packages for review is > already listed as a Contributor with CVS access. Why does this distinction matter? > > If a trusted contributor "NACK"s a package, they have to provide a > reason, and the package cannot be submitted to CVS until the problem > causing the NACK is lifted, or the trusted contributor withdraws the > NACK. > > Ideally, I'd like to do this in bugzilla.redhat.com. Perhaps we can > create a fedora-extras-QA component, and have new packages for review be > assigned to that. This component would go to all trusted contributors > (and/or fedora-extras-list) by default. > > As is now, we're losing track of packages, no one knows when a review is > sufficient. The old bugzilla fedora.us system worked well for this, and > I don't see any reason why it shouldn't be adapted for FE. Yes, the lack of database tracking is the key reason why the current process is confusing. We all agree that a fairly easy to implement ideal would be a stripped down Bugzilla interface with tickets, state changes and resolution. I don't know the status of the past proposed meetings between folks and dkl to make this happen. Anyone know? > > The Red Hat folks should already be comfortable with the ACK system, so > it gives the best of both worlds. > > I think assigning the "QA" group to the trusted contributors maps well > to the added responsibility of that role. If you're willing to sponsor > people, then you should be willing to QA new packages. > > What do you think? If people like the idea, I could document it this > weekend, and we can start following it. NEW -> NEEDSWORK -> APPROVED -> COMPLETED REJECTED (with reason given like legal) I think ACK or NACK is an oversimplification. We need explicit states something like below, and any of those steps can be skipped at any time. When you change a state give reasons just like regular Bugzilla comments. Tracking is the key to making the process less confusing. More and clearer documentation would help. A simplified Bugzilla interface would help. Warren Togami wtogami at redhat.com From thm at duke.edu Thu Apr 7 23:44:31 2005 From: thm at duke.edu (Hunter Matthews) Date: Thu, 07 Apr 2005 19:44:31 -0400 Subject: Suggestion for standardization In-Reply-To: <1112900771.3808.50.camel@localhost.localdomain> References: <1112900771.3808.50.camel@localhost.localdomain> Message-ID: <1112917471.2839.57.camel@jade.biology.duke.edu> On Thu, 2005-04-07 at 15:06, Tom 'spot' Callaway wrote: > The package review process is utterly confusing to me, so it can't make > much more sense to everyone else. Good, cuz I'm in the weeds at the moment. > What do you think? If people like the idea, I could document it this > weekend, and we can start following it. I like the idea, but it seems like its going to be hard to get trusted contributors to ACK something - I have you and Jose who've reviewed the bioperl stuff - is that enough? It might also make sense to put the legal or whoever people in bugzilla as well, so that outstanding requests for CVS access can be documented there - I have no idea what my CVS status is at the moment. -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From thm at duke.edu Thu Apr 7 23:48:02 2005 From: thm at duke.edu (Hunter Matthews) Date: Thu, 07 Apr 2005 19:48:02 -0400 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <1112850509.20996.187.camel@mccallum.corsepiu.local> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> <1112806757.2839.14.camel@jade.biology.duke.edu> <1112850509.20996.187.camel@mccallum.corsepiu.local> Message-ID: <1112917682.2839.60.camel@jade.biology.duke.edu> On Thu, 2005-04-07 at 01:08, Ralf Corsepius wrote: > On Wed, 2005-04-06 at 12:59 -0400, Hunter Matthews wrote: > > On Wed, 2005-04-06 at 11:47, Jos? Pedro Oliveira wrote: > > > Hunter, > > > > > > A couple of notes about the specfiles: > > > > > > * License > > > > > > License: GPL or Artistic > > > > I was unaware perl was dual licensed. Ok - fixing now. > Well, Perl is dual licensed, but individual modules aren't necessarily. > > Some of them are pure GPL, some of them are pure Artistic and some of > them come under other licenses. In theory you'll have to look up each > module's licensing anew. > I originally checked when I created each spec file, and unless I missed one, each was "under the same license as perl" or words to that effect - which is why I put artistic on each one. I've corrected all the spec files to now say "GPL or Artistic" -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From thm at duke.edu Thu Apr 7 23:52:22 2005 From: thm at duke.edu (Hunter Matthews) Date: Thu, 07 Apr 2005 19:52:22 -0400 Subject: Request for Review: bioperl and its dependancies In-Reply-To: <20050407120944.3b048803.bugs.michael@gmx.net> References: <1112390969.2932.142.camel@jade.biology.duke.edu> <42540499.8090408@di.uminho.pt> <1112806757.2839.14.camel@jade.biology.duke.edu> <1112850509.20996.187.camel@mccallum.corsepiu.local> <20050407120944.3b048803.bugs.michael@gmx.net> Message-ID: <1112917942.2839.66.camel@jade.biology.duke.edu> On Thu, 2005-04-07 at 06:09, Michael Schwendt wrote: > On Thu, 07 Apr 2005 07:08:29 +0200, Ralf Corsepius wrote: > > > > > > > > > * URL > > > > > > > > If the module is available in CPAN don't use a URL > > > > that contains the author id and the module version. > > > > > > > > Example: > > > > Use > > > > http://search.cpan.org/dist/Heap/ > > > > instead of > > > > http://search.cpan.org/~jmm/Heap-0.70/ > > > > > > > I was using the urls provided when I searched cpan itself. > > > > > > Is this requirement documented anywhere? > > > > I am not aware about such a requirement. But even if, this should be > > reconsidered. > > There is no such requirement. > > This shows that even without a "QA checklist" different reviewers suggest > different changes based on personal preference, aesthetics or special > expertise. And I'm afraid, that won't change ever. Unless we return to > fedora.us style of marking items as "blockers" and "non-blockers" (or > "suggestions"/"hints", respectively). > Sigh. I needed to go through and fix the license tags on all those spec files (as documented elsewhere) but had this been the only review "suggestion" i'd be mightly irritated at "fixing" something that wasn't broken. Can we please slug "required -violates wiki/foo/blarg#whatever" "suggested -nicer to QA people" "personal pref -your typical spec file is crap, and you're stupid" or something to each recommended change in a review? As a potential new contributor, see-sawing back and forth between different review preferences makes me not want to do something else instead. -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From bugs.michael at gmx.net Fri Apr 8 00:35:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 8 Apr 2005 02:35:46 +0200 Subject: Suggestion for standardization In-Reply-To: <1112900771.3808.50.camel@localhost.localdomain> References: <1112900771.3808.50.camel@localhost.localdomain> Message-ID: <20050408023546.6736b808.bugs.michael@gmx.net> On Thu, 07 Apr 2005 14:06:11 -0500, Tom 'spot' Callaway wrote: > The package review process is utterly confusing to me, so it can't make > much more sense to everyone else. Right. In addition to that, the sponsoring process is still confusing IMO, too. It's an all-or-nothing process. Either you sponsor a person _and_ the person's entire set of new packages. Or you don't sponsor the person at all, because you don't have the time and interest to review all the new packages and future cvs commits. [more at the bottom...] > I propose that we adopt an "ACK" style system, where trusted > contributors can ACK a package on review, two ACKs (maybe three?) will > mark it as approved/sponsored. The trusted contributor providing the > second ACK closes the bugzilla. Doesn't work for me. There is no tracking in our current reviewing process at all. I could not give my blessing to package reviews which don't document _what was reviewed_. Except for a few old-school fedora.us dudes, who have continued to post clearsigned approvals including source tarball checksums, approvals for other packages either have been informal messages or missing. If I were to "ACK something", I would need to verify a person's review and add my own checks. If I cannot see whether source tarball checksums have been verified with detached GPG signatures (if available) or packages from other big distributions or via diffs against previous releases, I would need to assume that a packager and or reviewer trusts the upstream project's download site ultimately. Similarly, without a comment on perceived runtime stability of a packaged software version, I could not verify the reviewer in that area either. I cannot simply assume that binaries were built and tested by other reviewers, if there is no review which documents such steps. Reviewing would be restricted to spec file changes, which would be the only visible steps of the reviewing process. It is not clear at all how to build up trust in such a scheme. commits-list is excellent for monitoring activity in CVS. Reviewing, on the contrary, so far has concentrated on spec adjustments and nitpicking. > This presumes that the person submitting new packages for review is > already listed as a Contributor with CVS access. This doesn't fix the old fedora.us pitfall of lack of scalability. So-called "trusted developers" could not include some of their _new_ packages, because they were in need of reviews, but didn't get reviews for every package. Not even from fellow trusted developers. Nobody was obliged to review new packages. Once a Fedora Extras Contributor is sponsored and does have CVS access, who does all reviews? Contrary to the initial "sponsors have to be willing to fix stuff if a sponsored person goes crazy and breaks stuff", the SponsorProcess page in the Wiki covers in more detail already what a sponsor's obligations seem to be (and it's just a first draft of a document!). > As is now, we're losing track of packages, no one knows when a review is > sufficient. The old bugzilla fedora.us system worked well for this, and > I don't see any reason why it shouldn't be adapted for FE. Because it required reviewers to do more work, e.g. process the QA checklist step by step, most likely required them to review a package painstakingly and document reviewed items. And only few people were willing to adhere to such a policy and do reviews, which looked as if they were difficult. > I think assigning the "QA" group to the trusted contributors maps well > to the added responsibility of that role. If you're willing to sponsor > people, then you should be willing to QA new packages. This won't work. I sponsor _a person_, not all the future packages a person might want to get included. In the decision finding process as whether to sponsor a person or not, an initial set of packages and the communication about them take a prominent role. But once a person is sponsored and imports a couple of reviewed and approved packages, there must be a way for the person to increase trust, so sponsors need not review each and every cvs commit forever and can switch to guiding new people into the system. This is not something to treat lightly. From bugs.michael at gmx.net Fri Apr 8 00:38:21 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 8 Apr 2005 02:38:21 +0200 Subject: Suggestion for standardization In-Reply-To: <1112917471.2839.57.camel@jade.biology.duke.edu> References: <1112900771.3808.50.camel@localhost.localdomain> <1112917471.2839.57.camel@jade.biology.duke.edu> Message-ID: <20050408023821.77add899.bugs.michael@gmx.net> On Thu, 07 Apr 2005 19:44:31 -0400, Hunter Matthews wrote: > It might also make sense to put the legal or whoever people in bugzilla > as well, so that outstanding requests for CVS access can be documented > there - I have no idea what my CVS status is at the moment. http://fedoraproject.org/wiki/Extras/Contributors Look at the top. That's current status. ;) From dgregor at redhat.com Fri Apr 8 05:25:21 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Fri, 08 Apr 2005 01:25:21 -0400 Subject: Suggestion for standardization In-Reply-To: <20050408023821.77add899.bugs.michael@gmx.net> References: <1112900771.3808.50.camel@localhost.localdomain> <1112917471.2839.57.camel@jade.biology.duke.edu> <20050408023821.77add899.bugs.michael@gmx.net> Message-ID: <1112937921.23830.16.camel@dhcp83-103.boston.redhat.com> On Fri, 2005-04-08 at 02:38 +0200, Michael Schwendt wrote: > On Thu, 07 Apr 2005 19:44:31 -0400, Hunter Matthews wrote: > > > It might also make sense to put the legal or whoever people in bugzilla > > as well, so that outstanding requests for CVS access can be documented > > there - I have no idea what my CVS status is at the moment. > > http://fedoraproject.org/wiki/Extras/Contributors > > Look at the top. That's current status. ;) I would like to add myself to that page, but I'm not sure where I fit in. I have been at Red Hat for over three years, but I was not involved in fedora.us work. My interest in Fedora Extras maintainership is Perl packages, and I currently maintain the perl-Class-MethodMaker and perl- Config-Record packages. I'm also interested in working on the Extras build system. Here's my templated introduction: 1. Full Legal Name Dennis Gregorovic 2. Profession or student status Release Engineer at Red Hat (3 years) 3. Company or School Red Hat 4. Your Goals in the Fedora Project Help it succeed. In particular, I hope to help the Extras build system along, and I also plan on maintaining several Perl packages. 5. Historical Qualifications I don't have much open source experience, except for Test-AutoBuild (www.autobuild.org). I've been doing software development professionally for 5 years, and before that I got a BS and MEng in CS at MIT. 6. GPG KEYID and fingerprint pub 1024D/DB5B842B 2004/04/20 Dennis Gregorovic Dennis Gregorovic Dennis Gregorovic (at work) Cheers -- Dennis > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list From a.kurtz at hardsun.net Fri Apr 8 06:05:34 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 07 Apr 2005 23:05:34 -0700 Subject: Self-Introduction: Aaron Kurtz + Wiki EditGroup request Message-ID: <1112940334.20642.35.camel@rydia.hardsun.net> Hi. I'm interested in working on Fedora Extras packages and so I'd like to introduce myself. My full legal name is Aaron Kurtz, and I live in Glendale, California. I am a student at Pasadena Community College. My goal for Fedora is to add programs that I would end up installing from 3rd party RPMs or compiling myself, such as the image viewer app feh, which I've already posted about here and Ignacio Vazquez-Abrams sponsored and imported. As for historical qualifications, I've used Redhat since the 5.2 days and understand it decently well, but I haven't got involved before except for packaging gtypist for rhcontrib back when that was active and answering the occasional question on #fedora. I do a little C and perl, but prefer Python. GPG fingerprint: pub 1024D/ED588CF2 2001-11-22 Key fingerprint = D719 23B0 BD2B CFF2 C81B E245 FB30 BB7B ED58 8CF2 uid Aaron Kurtz uid Aaron Kurtz sub 2048g/54E27295 2001-11-22 Also, could someone add me to the EditGroup on the fedoraproject.org wiki so I can request builds and a bugzilla component for feh. My wiki account name is AaronKurtz. -- Aaron Kurtz GPG Key ID: ED588CF2 -------------- 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 Fri Apr 8 13:27:53 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 08 Apr 2005 23:27:53 +1000 Subject: Self-Introduction: Aaron Kurtz + Wiki EditGroup request In-Reply-To: <1112940334.20642.35.camel@rydia.hardsun.net> References: <1112940334.20642.35.camel@rydia.hardsun.net> Message-ID: <1112966873.18379.335.camel@arena.soho.bytebot.net> On Thu, 2005-04-07 at 23:05 -0700, Aaron Kurtz wrote: > Also, could someone add me to the EditGroup on the fedoraproject.org > wiki so I can request builds and a bugzilla component for feh. My wiki > account name is AaronKurtz. Done. -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ivazquez at ivazquez.net Fri Apr 8 15:27:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 08 Apr 2005 11:27:44 -0400 Subject: lock-keys-applet build failure on x86_64 Message-ID: <1112974064.3405.95.camel@ignacio.ignacio.lan> Okay, here's the error I'm getting: gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -o lock-keys-applet lock-keys-applet.o -Wl,--export-dynamic -pthread -L/usr/X11R6/lib64 -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -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 /usr/lib/libpopt.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status I've seen this error in the IRC channels before, and my response has been to remove popt.i386. Obviously this won't work in a mach environment, so I was wondering if someone could please take a look at lock-keys-applet and figure out what changes would be required to have it build properly. Or if I could get access to a x86_64 machine myself for testing purposes that would be great as well. 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 bugs.michael at gmx.net Fri Apr 8 16:04:03 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 8 Apr 2005 18:04:03 +0200 Subject: lock-keys-applet build failure on x86_64 In-Reply-To: <1112974064.3405.95.camel@ignacio.ignacio.lan> References: <1112974064.3405.95.camel@ignacio.ignacio.lan> Message-ID: <20050408180403.698a66fd.bugs.michael@gmx.net> On Fri, 08 Apr 2005 11:27:44 -0400, Ignacio Vazquez-Abrams wrote: > Okay, here's the error I'm getting: > > gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona > -o lock-keys-applet lock-keys-applet.o -Wl,--export-dynamic -pthread > -L/usr/X11R6/lib64 -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -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 > /usr/lib/libpopt.so: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > > I've seen this error in the IRC channels before, and my response has > been to remove popt.i386. Obviously this won't work in a mach > environment, so I was wondering if someone could please take a look at > lock-keys-applet and figure out what changes would be required to have > it build properly. > > Or if I could get access to a x86_64 machine myself for testing purposes > that would be great as well. > > Thanks, Take a look at the previous line in the build log: /bin/sh ../libtool --mode=link gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -o lock-keys-applet lock-keys-applet.o -Wl,--export-dynamic -pthread -L/usr/X11R6/lib64 -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -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 You can see that ../libtool is called with good linker arguments for libpopt as taken from the libgnome-2.0 pkgconfig file. But this libtool doesn't care about /usr/lib64 and chooses to take libpopt.so from /usr/lib instead when running gcc, which is what you see in the line you quoted. So, if you update the included libtool files (libtoolize...), that should fix it. From ivazquez at ivazquez.net Fri Apr 8 18:27:29 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 08 Apr 2005 14:27:29 -0400 Subject: lock-keys-applet build failure on x86_64 In-Reply-To: <20050408180403.698a66fd.bugs.michael@gmx.net> References: <1112974064.3405.95.camel@ignacio.ignacio.lan> <20050408180403.698a66fd.bugs.michael@gmx.net> Message-ID: <1112984849.8034.0.camel@ignacio.ignacio.lan> On Fri, 2005-04-08 at 18:04 +0200, Michael Schwendt wrote: > Take a look at the previous line in the build log: > > /bin/sh ../libtool --mode=link gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -o lock-keys-applet lock-keys-applet.o -Wl,--export-dynamic -pthread -L/usr/X11R6/lib64 -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -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 > > You can see that ../libtool is called with good linker arguments for > libpopt as taken from the libgnome-2.0 pkgconfig file. But this libtool > doesn't care about /usr/lib64 and chooses to take libpopt.so from /usr/lib > instead when running gcc, which is what you see in the line you > quoted. So, if you update the included libtool files (libtoolize...), > that should fix it. Aha, thanks. Hopefully the fix I applied should do 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 shishz at hotpop.com Sat Apr 9 08:51:23 2005 From: shishz at hotpop.com (Zing) Date: Sat, 09 Apr 2005 04:51:23 -0400 Subject: mach/yum build environment help Message-ID: Hello folks, I'm new to mach (using seth's mach/yum build environment) and I'm wondering if i setup something not right. i've gotten as far as a successful build i think but... ./build.sh perl-XML-LibXSLT Building as i386 on fedora-development-i386-core with branch devel Making srpm of perl-XML-LibXSLT Run Mach (Y/n): Removing 8 packages ... .... Getting /home/zbuild/build/extras/srpms/perl-XML-LibXSLT-1.57-4.src.rpm ... Removing 1 packages ... .... Building source rpm perl-XML-LibXSLT-1.57-4.src.rpm Installing BuildRequires ...... Rebuilding source rpm perl-XML-LibXSLT-1.57-4.src.rpm ..... Collecting results of build /usr/src/rpm/SRPMS/perl-XML-LibXSLT-1.57-4.src.rpm Build of perl-XML-LibXSLT-1.57-4 succeeded, results in /var/tmp/mach/fedora-development-i386-core/perl-XML-LibXSLT-1.57-4 Results: /var/tmp/mach/fedora-development-i386-core/perl-XML-LibXSLT-1.57-4 Build done. ...that perl-XML-LibXSLT directory is empty... is that normal? And a second question, I had to change the buildrequires: from perl(XML::LibXML) >= 1.57 to perl-XML-LibXML >= 1.57 otherwise i get ERROR: BuildRequires not met. Is this something one just needs to do, or is it a bug? thanks, zing From ville.skytta at iki.fi Sat Apr 9 11:08:59 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 09 Apr 2005 14:08:59 +0300 Subject: mach/yum build environment help In-Reply-To: References: Message-ID: <1113044939.5228.105.camel@bobcat.mine.nu> On Sat, 2005-04-09 at 04:51 -0400, Zing wrote: > And a second question, I had to change the buildrequires: from > perl(XML::LibXML) >= 1.57 to perl-XML-LibXML >= 1.57 otherwise i get > ERROR: BuildRequires not met. Is this something one just needs to do, or > is it a bug? perl-XML-LibXML-1.58-[12] provides "perl(XML::LibXML) = 1.58", so it's a bug or an unimplemented feature somewhere. Placing the above workaround to the perl-XML-LibXSLT specfile isn't that big a deal though. From bugs.michael at gmx.net Sat Apr 9 11:11:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 9 Apr 2005 13:11:20 +0200 Subject: Looking for a sponsor In-Reply-To: <485bb884050320132825351809@mail.gmail.com> References: <485bb88405031617557e855e23@mail.gmail.com> <485bb884050320132825351809@mail.gmail.com> Message-ID: <20050409131120.7157dae4.bugs.michael@gmx.net> On Sun, 20 Mar 2005 13:28:45 -0800, Michael Peters wrote: > I'm still looking for a sponsor. > I think slimserver needs to go into livna - but there are some perl > modules that it needs that will need to be available in extras. > > At this point I've packaged three of them (only tested in fc4t1) > > This one is needed by slimserver : > > http://mpeters.us/sleek/fc4_perl_support/perl-Template-Toolkit-2.14-0.0.yjl.0.testing.1.src.rpm ERROR 404: Not Found. > It does contain a binary component. > > These two are needed by the above perl package and are noarch : > > http://mpeters.us/sleek/fc4_perl_support/perl-Text-Autoformat-1.12-0.0.yjl.0.testing.1.src.rpm ERROR 404: Not Found. > http://mpeters.us/sleek/fc4_perl_support/perl-Tie-DBI-1.01-0.0.yjl.0.testing.1.src.rpm ERROR 404: Not Found. From dgregor at redhat.com Sat Apr 9 14:54:37 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Sat, 09 Apr 2005 10:54:37 -0400 Subject: mach/yum build environment help In-Reply-To: References: Message-ID: <1113058477.23830.83.camel@dhcp83-103.boston.redhat.com> On Sat, 2005-04-09 at 04:51 -0400, Zing wrote: > And a second question, I had to change the buildrequires: from > perl(XML::LibXML) >= 1.57 to perl-XML-LibXML >= 1.57 otherwise i get > ERROR: BuildRequires not met. Is this something one just needs to do, or > is it a bug? > Which version of Yum are you using? If I recall correctly, Seth added support for resolution of virtual BuildRequires recently. Try grabbing something more recent from http://linux.duke.edu/projects/yum/download/ Cheers -- Dennis From dwmw2 at infradead.org Sat Apr 9 16:47:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 09 Apr 2005 17:47:33 +0100 Subject: bmp still requires ExcludeArch? In-Reply-To: <20050324130412.584e20df@nausicaa.camperquake.de> References: <1111644720.24837.16.camel@arena.soho.bytebot.net> <20050324130412.584e20df@nausicaa.camperquake.de> Message-ID: <1113065254.4636.34.camel@localhost.localdomain> On Thu, 2005-03-24 at 13:04 +0100, Ralf Ertzinger wrote: > The last time I tested that it compiled, started up, and threw a lot > of noise at me when trying to play .ogg (or .mp3, for that matter). > Will test again. This is probably because it was telling the hardware to expect 16-bit little-endian samples, then feeding it big-endian. It should be fairly simple to fix. -- dwmw2 From dwmw2 at infradead.org Sat Apr 9 16:48:15 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 09 Apr 2005 17:48:15 +0100 Subject: Fedora Extras Development/ppc In-Reply-To: <1111645941.24837.23.camel@arena.soho.bytebot.net> References: <1111645941.24837.23.camel@arena.soho.bytebot.net> Message-ID: <1113065297.4636.37.camel@localhost.localdomain> On Thu, 2005-03-24 at 17:32 +1100, Colin Charles wrote: > Build machine is a FC4test1/ppc32 box, and I know we're talking about > developers debugging stuff, but its not publically accessible from the > Net (sorry). But I'm willing to try fixes, etc... as your patch queue > monkey even to see if it starts working on PPC. E-mail > colin at fedoraproject.org (or cc) with the subject line PQM: or > something I can also provide access to FC3/ppc, so if you can reproduce the same problems there you can use that for debugging. -- dwmw2 From fedora at camperquake.de Sat Apr 9 16:49:32 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 9 Apr 2005 18:49:32 +0200 Subject: bmp still requires ExcludeArch? In-Reply-To: <1113065254.4636.34.camel@localhost.localdomain> References: <1111644720.24837.16.camel@arena.soho.bytebot.net> <20050324130412.584e20df@nausicaa.camperquake.de> <1113065254.4636.34.camel@localhost.localdomain> Message-ID: <20050409184932.47bbb030@nausicaa.camperquake.de> Hi. David Woodhouse wrote: > This is probably because it was telling the hardware to expect 16-bit > little-endian samples, then feeding it big-endian. It should be fairly > simple to fix. I thought that, too, but for some-mysterious-reason-or-the-other it is working just fine now. -- Lay the Legacy to rest.... From perbj at stanford.edu Sat Apr 9 20:08:04 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Sat, 09 Apr 2005 13:08:04 -0700 Subject: Laptop-mode-tools, and self-reintroduction Message-ID: <1113077285.17730.25.camel@localhost.localdomain> Hi, I introduced myself on the Fedora-devel list a long time ago (https://www.redhat.com/archives/fedora-devel-list/2004- March/msg00316.html ) but for various reasons I haven't really been able to contribute much more than random comments on the mailing lists as of yet. Well, I'd like to change that. If someone could add me to the Wiki EditGroup (I'm PerBjornsson) so I could request sponsorship, I'd really appreciate it. In general, my main interests in Fedora are desktop- oriented, and I'd like to help package various programs that I find useful in day-to-day life. One thing that drives me nuts is that my laptop has too little battery life. Something that fixes this up a bit is the laptop-mode (which is a kernel feature) together with the control scripts. Unfortunately, the control scripts (laptop-mode-tools) are not shipped with Fedora, so I packaged them up: http://www.stanford.edu/~perbj/fedora/SRPMS/laptop-mode- tools-1.04-0.1.src.rpm http://www.stanford.edu/~perbj/fedora/RPMS/laptop-mode- tools-1.04-0.1.noarch.rpm Note that for a while the scripts were stuffed in the kernel Documentation/laptop-mode.txt file, but what's there is outdated now, this package should be better. Also, I used the 0.1 release tag since these are not official Fedora packages yet; they are signed with my GPG key (0x7201315D, available from pgp.mit.edu). As far as I can tell the package seems to do the right thing with ACPI in any case; I belive that APM should also work out of the box, but that the PPC power management daemons need some additional configuration in order to use this. (I'm consideering whether I should have the installation do an acpid reload after installation; otherwise they won't actually kick in until next boot, or at least until somthing kicks the ACPI daemon...) In principle I think that this might want to be integrated in some more universal power management daemon (such as Gnome-power-manager) but as far as I can tell that won't really be a realistic option for FC4 in any case. I think that this is a nice interim measure and it should be easy to replace with something better once that comes along. I've got some other packages that I'd like to see as well of course, but one step at a time... Best regards, Per Bjornsson -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University -------------- 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 toshio at tiki-lounge.com Sat Apr 9 21:14:52 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 09 Apr 2005 17:14:52 -0400 Subject: Review needed: notecase In-Reply-To: <1112839017.8621.11.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> <1112825276.3405.33.camel@ignacio.ignacio.lan> <1112839017.8621.11.camel@Madison.badger.com> Message-ID: <1113081293.4347.3.camel@Madison.badger.com> On Wed, 2005-04-06 at 21:56 -0400, Toshio wrote: > > I noticed several gcc warnings that I think can be fixed by changing > int/unsigned int's into long/unsigned long's. Too tired to test changes > ATM, but some of them do look to need fixing in order to make notecase > run correctly on 64 bit. Patch to fix gcc warnings under AMD64. Verified it runs on AMD_64 but haven't put it through anything strenuous (network login.) Let me know when you have another checkin to cvs that you need reviewed. -Toshio -- ________S_________U_________B_________L_________I_________M_________E________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: notecase-x86_64.patch Type: text/x-patch Size: 1870 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 Sat Apr 9 22:40:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 10 Apr 2005 00:40:55 +0200 Subject: Laptop-mode-tools, and self-reintroduction In-Reply-To: <1113077285.17730.25.camel@localhost.localdomain> References: <1113077285.17730.25.camel@localhost.localdomain> Message-ID: <20050410004055.5a1b8b09.bugs.michael@gmx.net> On Sat, 09 Apr 2005 13:08:04 -0700, Per Bjornsson wrote: > Hi, > > I introduced myself on the Fedora-devel list a long time ago > (https://www.redhat.com/archives/fedora-devel-list/2004- > March/msg00316.html ) but for various reasons I haven't really been able > to contribute much more than random comments on the mailing lists as of > yet. Well, I'd like to change that. If someone could add me to the Wiki > EditGroup (I'm PerBjornsson) so I could request sponsorship, I'd really > appreciate it. The page is freely editable. But I added your account to EditGroup nevertheless. From wtogami at redhat.com Sun Apr 10 08:04:28 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 09 Apr 2005 22:04:28 -1000 Subject: Laptop-mode-tools, and self-reintroduction In-Reply-To: <1113077285.17730.25.camel@localhost.localdomain> References: <1113077285.17730.25.camel@localhost.localdomain> Message-ID: <4258DE0C.8020802@redhat.com> Per Bjornsson wrote: > One thing that drives me nuts is that my laptop has too little battery > life. Something that fixes this up a bit is the laptop-mode (which is a > kernel feature) together with the control scripts. Unfortunately, the > control scripts (laptop-mode-tools) are not shipped with Fedora, so I > packaged them up: > > http://www.stanford.edu/~perbj/fedora/SRPMS/laptop-mode- > tools-1.04-0.1.src.rpm > http://www.stanford.edu/~perbj/fedora/RPMS/laptop-mode- > tools-1.04-0.1.noarch.rpm > > Note that for a while the scripts were stuffed in the kernel > Documentation/laptop-mode.txt file, but what's there is outdated now, > this package should be better. Also, I used the 0.1 release tag since > these are not official Fedora packages yet; they are signed with my GPG > key (0x7201315D, available from pgp.mit.edu). > > As far as I can tell the package seems to do the right thing with ACPI > in any case; I belive that APM should also work out of the box, but that > the PPC power management daemons need some additional configuration in > order to use this. (I'm consideering whether I should have the > installation do an acpid reload after installation; otherwise they won't > actually kick in until next boot, or at least until somthing kicks the > ACPI daemon...) > > In principle I think that this might want to be integrated in some more > universal power management daemon (such as Gnome-power-manager) but as > far as I can tell that won't really be a realistic option for FC4 in any > case. I think that this is a nice interim measure and it should be easy > to replace with something better once that comes along. > Have to put a hold on this, because it sounds like it will conflict with the work davidz is working on for FC4 Core. David should review what you have here and communicate his plans and existing packages. This was previous discussed in fedora-maint list, you can read the archives here: http://www.redhat.com/mailman/listinfo/fedora-maintainers See the thread "STR working out of the box" which began during March. Warren Togami wtogami at redhat.com From perbj at stanford.edu Sun Apr 10 09:26:39 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Sun, 10 Apr 2005 02:26:39 -0700 Subject: Laptop-mode-tools, and self-reintroduction In-Reply-To: <4258DE0C.8020802@redhat.com> References: <1113077285.17730.25.camel@localhost.localdomain> <4258DE0C.8020802@redhat.com> Message-ID: <1113125200.17730.45.camel@localhost.localdomain> On Sat, 2005-04-09 at 22:04 -1000, Warren Togami wrote: > Have to put a hold on this, because it sounds like it will conflict with > the work davidz is working on for FC4 Core. David should review what > you have here and communicate his plans and existing packages. This was > previous discussed in fedora-maint list, you can read the archives here: > http://www.redhat.com/mailman/listinfo/fedora-maintainers > > See the thread "STR working out of the box" which began during March. OK. To me it seemed like that thread mostly dealt with suspend-to-RAM, I didn't realize that other power related stuff was involved. As far as I can tell, fixing up STR seems pretty orthogonal to saving power while the computer is awake but it would certainly make sense to deal with all power management stuff in an organized fashion. Thanks, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From wtogami at redhat.com Sun Apr 10 09:33:43 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 09 Apr 2005 23:33:43 -1000 Subject: Laptop-mode-tools, and self-reintroduction In-Reply-To: <1113125200.17730.45.camel@localhost.localdomain> References: <1113077285.17730.25.camel@localhost.localdomain> <4258DE0C.8020802@redhat.com> <1113125200.17730.45.camel@localhost.localdomain> Message-ID: <4258F2F7.30203@redhat.com> Per Bjornsson wrote: > > > OK. To me it seemed like that thread mostly dealt with suspend-to-RAM, I > didn't realize that other power related stuff was involved. As far as I > can tell, fixing up STR seems pretty orthogonal to saving power while > the computer is awake but it would certainly make sense to deal with all > power management stuff in an organized fashion. Woops, I should have actually read the code in the tarball. I guess it is pretty orthogonal, however let's be sure each piece fits. Maybe it would be appropriate to put both STR and laptop-mode scripts into FC4 Core. Hmm with laptop_mode engaged, does it properly sync before going into suspend? Suspend is often hazardous and it could very easily kill 10 minutes of data. =) Warren Togami wtogami at redhat.com From cra at WPI.EDU Sun Apr 10 09:47:57 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Sun, 10 Apr 2005 05:47:57 -0400 Subject: Laptop-mode-tools, and self-reintroduction In-Reply-To: <4258F2F7.30203@redhat.com> References: <1113077285.17730.25.camel@localhost.localdomain> <4258DE0C.8020802@redhat.com> <1113125200.17730.45.camel@localhost.localdomain> <4258F2F7.30203@redhat.com> Message-ID: <20050410094756.GJ1904@angus.ind.WPI.EDU> On Sat, Apr 09, 2005 at 11:33:43PM -1000, Warren Togami wrote: > Per Bjornsson wrote: > Hmm with laptop_mode engaged, does it properly sync before going into > suspend? Suspend is often hazardous and it could very easily kill 10 > minutes of data. =) I haven't looked at the new stuff yet, but one problem I have with my current ACPI setup is after shutting down, I close the lid which suspends the laptop mid-shutdown. I hope the new scripts will handle this by turning off ACPI events during shutdown. From symbiont at berlios.de Sun Apr 10 14:12:28 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 10 Apr 2005 22:12:28 +0800 Subject: mach/yum build environment help In-Reply-To: <1113058477.23830.83.camel@dhcp83-103.boston.redhat.com> References: <1113058477.23830.83.camel@dhcp83-103.boston.redhat.com> Message-ID: <200504102212.29003.symbiont@berlios.de> On Saturday 09 April 2005 22:54, Dennis Gregorovic wrote: > Which version of Yum are you using? ?If I recall correctly, Seth > added support for resolution of virtual BuildRequires recently. ?Try > grabbing something more recent from > http://linux.duke.edu/projects/yum/download/ The resolution is done in mach itself, unless Seth's patched it to use yum's resolver. That would be cool... -- -jeff From Jochen at herr-schmitt.de Sun Apr 10 17:35:37 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 10 Apr 2005 19:35:37 +0200 Subject: Request for Preview: INADYN In-Reply-To: <1112906227.3405.81.camel@ignacio.ignacio.lan> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> Message-ID: On Thu, 07 Apr 2005 16:37:07 -0400, you wrote: >On Thu, 2005-04-07 at 19:19 +0200, Jochen Schmitt wrote: >> http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-0.2.src.rpm >> >> is a lightwight DynDNS client wrttien in puer C. > >? Name and version macros at the top >? Incorrect release number >- Superflous Epoch 0 >- Summary contains the package name >- What happened to %setup? >- Doesn't remove the buildroot at the beginning of %install >- No modes on install >- Doesn't use macros throughout %install >- Don't create %{_docdir} manually >- No changelog > >Corrected spec file is attached. Thank you for your comments. I have modifiy the %setup macro to make clear, to which file the %setup macro is related. I have uploaded the corrected Source RPM to http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-2.src.rpm Best Regards: Jochen Schmitt From bugs.michael at gmx.net Sun Apr 10 17:47:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 10 Apr 2005 19:47:42 +0200 Subject: Request for Preview: INADYN In-Reply-To: References: <1112906227.3405.81.camel@ignacio.ignacio.lan> Message-ID: <20050410194742.3d1db659.bugs.michael@gmx.net> On Sun, 10 Apr 2005 19:35:37 +0200, Jochen Schmitt wrote: > On Thu, 07 Apr 2005 16:37:07 -0400, you wrote: > > >On Thu, 2005-04-07 at 19:19 +0200, Jochen Schmitt wrote: > >> http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-0.2.src.rpm > >> > >> is a lightwight DynDNS client wrttien in puer C. > > > >? Name and version macros at the top > >? Incorrect release number > >- Superflous Epoch 0 > >- Summary contains the package name > >- What happened to %setup? > >- Doesn't remove the buildroot at the beginning of %install > >- No modes on install > >- Doesn't use macros throughout %install > >- Don't create %{_docdir} manually > >- No changelog > > > >Corrected spec file is attached. > > Thank you for your comments. > > I have modifiy the %setup macro to make clear, to which file the > %setup macro is related. > > I have uploaded the corrected Source RPM to > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-2.src.rpm Some corrections: --- inadyn.spec.orig 2005-04-10 19:43:02.000000000 +0200 +++ inadyn.spec 2005-04-10 19:46:57.000000000 +0200 @@ -5,7 +5,7 @@ Group: System Environment/Daemons License: GPL -URL: http://inadyn.ina-tech.net +URL: http://inadyn.ina-tech.net Source0: inadyn.v%{version}.zip Source1: inadyn.conf BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -17,10 +17,10 @@ is running INADYN. %prep -%setup0 -q -c +%setup -q -c %build -make -f makefile.linux +make -f makefile.linux CFLAGS="$RPM_OPT_FLAGS" %install rm -rf $RPM_BUILD_ROOT @@ -30,8 +30,8 @@ mkdir -p $RPM_BUILD_ROOT%{_mandir}/man5 mkdir -p $RPM_BUILD_ROOT%{_mandir}/man8 -install -m 0644 man/inadyn.8 $RPM_BUILD_ROOT%{_mandir}/man8 -install -m 0644 man/inadyn.conf.5 $RPM_BUILD_ROOT%{_mandir}/man5 +install -p -m 0644 man/inadyn.8 $RPM_BUILD_ROOT%{_mandir}/man8 +install -p -m 0644 man/inadyn.conf.5 $RPM_BUILD_ROOT%{_mandir}/man5 mkdir -p $RPM_BUILD_ROOT%{_sysconfdir} install -p -m 0600 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir} @@ -44,7 +44,7 @@ %doc readme.html %{_sbindir}/inadyn %{_mandir}/man*/* -%config /etc/inadyn.conf +%config %{_sysconfdir}/inadyn.conf %changelog * Sun Apr 10 2005 Jochen Schmitt 1.90-2 From skvidal at phy.duke.edu Mon Apr 11 03:45:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 10 Apr 2005 23:45:05 -0400 Subject: mach/yum build environment help In-Reply-To: <200504102212.29003.symbiont@berlios.de> References: <1113058477.23830.83.camel@dhcp83-103.boston.redhat.com> <200504102212.29003.symbiont@berlios.de> Message-ID: <1113191105.2813.4.camel@cutter> On Sun, 2005-04-10 at 22:12 +0800, Jeff Pitman wrote: > On Saturday 09 April 2005 22:54, Dennis Gregorovic wrote: > > Which version of Yum are you using? If I recall correctly, Seth > > added support for resolution of virtual BuildRequires recently. Try > > grabbing something more recent from > > http://linux.duke.edu/projects/yum/download/ > > The resolution is done in mach itself, unless Seth's patched it to use > yum's resolver. That would be cool... which it has been. -sv From skvidal at phy.duke.edu Mon Apr 11 03:46:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 10 Apr 2005 23:46:14 -0400 Subject: mach/yum build environment help In-Reply-To: References: Message-ID: <1113191174.2813.7.camel@cutter> On Sat, 2005-04-09 at 04:51 -0400, Zing wrote: > Hello folks, > > I'm new to mach (using seth's mach/yum build environment) and I'm > wondering if i setup something not right. i've gotten as far as a > successful build i think but... > > ./build.sh perl-XML-LibXSLT > Building as i386 on fedora-development-i386-core with branch devel > Making srpm of perl-XML-LibXSLT > Run Mach (Y/n): Removing 8 packages ... .... > Getting /home/zbuild/build/extras/srpms/perl-XML-LibXSLT-1.57-4.src.rpm ... > Removing 1 packages ... .... > Building source rpm perl-XML-LibXSLT-1.57-4.src.rpm > Installing BuildRequires ...... > Rebuilding source rpm perl-XML-LibXSLT-1.57-4.src.rpm ..... > Collecting results of build /usr/src/rpm/SRPMS/perl-XML-LibXSLT-1.57-4.src.rpm > Build of perl-XML-LibXSLT-1.57-4 succeeded, results in > /var/tmp/mach/fedora-development-i386-core/perl-XML-LibXSLT-1.57-4 > Results: /var/tmp/mach/fedora-development-i386-core/perl-XML-LibXSLT-1.57-4 > Build done. > umm did you run mach -c ? if so the all the build results got moved to wherever your cwd was. > ...that perl-XML-LibXSLT directory is empty... is that normal? with mach -c, yes. > And a second question, I had to change the buildrequires: from > perl(XML::LibXML) >= 1.57 to perl-XML-LibXML >= 1.57 otherwise i get > ERROR: BuildRequires not met. Is this something one just needs to do, or > is it a bug? dunno - depends on the version of yum you have installed. -sv From skvidal at fedoraproject.org Mon Apr 11 05:55:03 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 11 Apr 2005 01:55:03 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1113198903.2813.28.camel@cutter> Hi Everyone, This is the report of the big-package-rebuild orchestrated by Michael Schwendt release bumping everything that hadn't been updated. Instead of posting successes I'm just going to post the list of packages which failed to rebuild. See the attached files for the failed package report for each architecture. If you see a build error then you should check out the logs located at: http://fedoraproject.org/extras/development/build-logs/ I think I got everything that should have been built, built. It's possible I missed something. I was sick this weekend so in a fever-dream-induced delirium something might have been futzed up. Thanks! -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: development-ppc.log Type: text/x-log Size: 814 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: development-i386.log Type: text/x-log Size: 1563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: development-x86_64.log Type: text/x-log Size: 92 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 mattdm at mattdm.org Mon Apr 11 15:00:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Apr 2005 11:00:55 -0400 Subject: wxPython In-Reply-To: <1112694150.6360.68.camel@localhost.localdomain> References: <1112658666.6360.64.camel@localhost.localdomain> <1112673280.3613.7.camel@rydia.hardsun.net> <1112694150.6360.68.camel@localhost.localdomain> Message-ID: <20050411150055.GA11785@jadzia.bu.edu> On Tue, Apr 05, 2005 at 10:42:30AM +0100, Paul wrote: > Thanks. wxPython needs rebuilding against python-2.4. It would also be nice if it were made to build against the upstream wxGTK package, rather than including its own. (I think this should be a goal for wxPython 2.6.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pmatilai at welho.com Mon Apr 11 15:17:11 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 11 Apr 2005 18:17:11 +0300 Subject: wxPython In-Reply-To: <20050411150055.GA11785@jadzia.bu.edu> References: <1112658666.6360.64.camel@localhost.localdomain> <1112673280.3613.7.camel@rydia.hardsun.net> <1112694150.6360.68.camel@localhost.localdomain> <20050411150055.GA11785@jadzia.bu.edu> Message-ID: <1113232631.30988.0.camel@localhost.localdomain> On Mon, 2005-04-11 at 11:00 -0400, Matthew Miller wrote: > On Tue, Apr 05, 2005 at 10:42:30AM +0100, Paul wrote: > > Thanks. wxPython needs rebuilding against python-2.4. > > It would also be nice if it were made to build against the upstream wxGTK > package, rather than including its own. (I think this should be a goal for > wxPython 2.6.... That's exactly how the current wxPython in extras is built. - Panu - From tcallawa at redhat.com Mon Apr 11 16:01:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 11:01:16 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits Message-ID: <1113235276.5021.62.camel@localhost.localdomain> All packages described can be found here: http://www.auroralinux.org/people/spot/R/ R is a free software environment for for statistical computing and graphics. It is widely used in higher education. It is similar to S, so similar, that most S code has been (or can be) ported to R. R is very modular, like perl or python. The base R package provides the R runtime environment and some core required modules. http://www.r-project.org/ There are a lot of R modules out there, and I intend on packaging most of them. The end goal is to enable Fedora Core as a platform for things like Bioconductor (http://www.bioconductor.org/), and make it more friendly for University use. I'm going to break the packages up into chunks for review and submission, since no one wants to review several hundred packages in one go. These packages are some of the missing dependencies of R and friends. ==== R: URL: http://www.r-project.org/ SRPM: http://www.auroralinux.org/people/spot/R/R-2.0.1-8.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/R.spec A language and environment for statistical computing and graphics. R is similar to the award-winning S system, which was developed at Bell Laboratories by John Chambers et al. It provides a wide variety of statistical and graphical techniques (linear and nonlinear modelling, statistical tests, time series analysis, classification, clustering, ...). R is designed as a true computer language with control-flow constructions for iteration and alternation, and it allows users to add additional functionality by defining new functions. For computationally intensive tasks, C, C++ and Fortran code can be linked and called at run time. QuantLib: URL: http://www.quantlib.org SRPM: http://www.auroralinux.org/people/spot/R/QuantLib-0.3.8-2.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/QuantLib.spec QuantLib is a free/open-source library for modeling, trading, and risk management in real-life. perl-Jcode: URL: http://www.cpan.org SRPM: http://www.auroralinux.org/people/spot/R/perl-Jcode-0.88-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/perl-Jcode.spec Jcode is a Perl extension interface to convert Japanese text. perl-OLE-Storage_Lite: URL: http://www.cpan.org SRPM:http://www.auroralinux.org/people/spot/R/perl-OLE-Storage_Lite-0.14-1.src.rpm SPEC:http://www.auroralinux.org/people/spot/R/perl-OLE-Storage_Lite.spec Simple Class for OLE document interface. perl-Spreadsheet-WriteExcel: URL: http://www.cpan.org SRPM:http://www.auroralinux.org/people/spot/R/perl-Spreadsheet-WriteExcel-2.12-1.src.rpm SPEC:http://www.auroralinux.org/people/spot/R/perl-Spreadsheet-WriteExcel.spec The Spreadsheet::WriteExcel module can be used to create a cross- platform Excel binary file. Multiple worksheets can be added to a workbook and formatting can be applied to cells. Text, numbers, formulas, hyperlinks and images can be written to the cells. The Excel file produced by this module is compatible with 97, 2000, 2002 and 2003. The module will work on the majority of Windows, UNIX and Macintosh platforms. Generated files are also compatible with the spreadsheet applications Gnumeric and OpenOffice.org. This module cannot be used to read an Excel file. See Spreadsheet::ParseExcel or look at the main documentation for some suggestions. This module cannot be uses to write to an existing Excel file. perl-Unicode-Map: URL: http://www.cpan.org SRPM: http://www.auroralinux.org/people/spot/R/perl-Unicode-Map-0.112-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/perl-Unicode-Map.spec This module converts strings from and to 2-byte Unicode UCS2 format. All mappings happen via 2 byte UTF16 encodings, not via 1 byte UTF8 encoding. To convert between UTF8 and UTF16 use Unicode::String. For historical reasons this module coexists with Unicode::Map8. Please use Unicode::Map8 unless you need to care for >1 byte character sets, e.g. chinese GB2312. Anyway, if you stick to the basic functionality (see documentation) you can use both modules equivalently. udunits: URL: http://my.unidata.ucar.edu/content/software/udunits/index.html SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec The Unidata units library, udunits, supports conversion of unit specifications between formatted and binary forms, arithmetic manipulation of unit specifications, and conversion of values between compatible scales of measurement. A unit is the amount by which a physical quantity is measured. For example: Physical Quantity Possible Unit _________________ _____________ time weeks distance centimeters power watts This utility works interactively and has two modes. In one mode, both an input and output unit specification are given, causing the utility to print the conversion between them. In the other mode, only an input unit specification is given. This causes the utility to print the definition -- in standard units -- of the input unit. ==== Thanks in advance, ~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 Jochen at herr-schmitt.de Mon Apr 11 16:15:35 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 11 Apr 2005 18:15:35 +0200 Subject: Request for Preview: INADYN In-Reply-To: <20050410194742.3d1db659.bugs.michael@gmx.net> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> Message-ID: <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> On Sun, 10 Apr 2005 19:47:42 +0200, you wrote: >> >> http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-2.src.rpm > >Some corrections: Corrected version was uploaded to http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm Best Regards: Jochen Schmitt From bugs.michael at gmx.net Mon Apr 11 16:18:39 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 11 Apr 2005 18:18:39 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113235276.5021.62.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> Message-ID: <20050411181839.4e397ca2.bugs.michael@gmx.net> On Mon, 11 Apr 2005 11:01:16 -0500, Tom 'spot' Callaway wrote: > udunits: > URL: http://my.unidata.ucar.edu/content/software/udunits/index.html > SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm > SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec For reference: https://bugzilla.fedora.us/show_bug.cgi?id=921 From tcallawa at redhat.com Mon Apr 11 16:28:28 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 11:28:28 -0500 Subject: Request for sponsor: gnet In-Reply-To: <1112789436.3405.13.camel@ignacio.ignacio.lan> References: <1112216349.8866.13.camel@ignacio.ignacio.lan> <1112789436.3405.13.camel@ignacio.ignacio.lan> Message-ID: <1113236909.5021.70.camel@localhost.localdomain> On Wed, 2005-04-06 at 08:10 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-03-30 at 15:59 -0500, Ignacio Vazquez-Abrams wrote: > > gnet: A simple network library built upon glib > > Anyone? Yes? No? Minor stylistic revisions: --- rpmbuild/SPECS/gnet2.spec.ORIG 2005-04-11 11:20:24.000000000 -0500 +++ rpmbuild/SPECS/gnet2.spec 2005-04-11 11:24:59.000000000 -0500 @@ -16,12 +16,13 @@ built upon GLib. It is intended to be easy to use and port. %package devel -Summary: Headers and libraries for building apps that use gnet +Summary: Headers and libraries for building apps that use gnet2 Group: Development/Libraries Requires: %{name} = %{version} %description devel -This package contains headers and libraries required to build applications that use GNet. +This package contains headers and libraries required to build +applications that use GNet2. %prep %setup -q -n gnet-%{version} @@ -59,4 +60,4 @@ %changelog * Wed Mar 30 2005 Ignacio Vazquez-Abrams 2.0.7-1 -Initial RPM release +- Initial RPM release Make those changes, and I'll sponsor its inclusion. ~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 ville.skytta at iki.fi Mon Apr 11 16:32:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Apr 2005 19:32:32 +0300 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113235276.5021.62.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> Message-ID: <1113237152.22499.47.camel@bobcat.mine.nu> On Mon, 2005-04-11 at 11:01 -0500, Tom 'spot' Callaway wrote: > perl-Jcode: > perl-Unicode-Map: These are already in Extras. From gemi at bluewin.ch Mon Apr 11 16:41:58 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 11 Apr 2005 18:41:58 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113235276.5021.62.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> Message-ID: <1113237718.21005.2.camel@scriabin.tannenrauch.ch> On Mon, 2005-04-11 at 11:01 -0500, Tom 'spot' Callaway wrote: > All packages described can be found here: > http://www.auroralinux.org/people/spot/R/ > > R is a free software environment for for statistical computing and > graphics. It is widely used in higher education. It is similar to S, so > similar, that most S code has been (or can be) ported to R. > R is very modular, like perl or python. The base R package provides the > R runtime environment and some core required modules. > http://www.r-project.org/ I had R for some time in my repository: http://math.ifi.unizh.ch/fedora/3/i386/SRPMS.gemi/R-2.0.1-1.src.rpm Whenever you bring R into Extras, I can remove it. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From bugs.michael at gmx.net Mon Apr 11 16:46:54 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 11 Apr 2005 18:46:54 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113237718.21005.2.camel@scriabin.tannenrauch.ch> References: <1113235276.5021.62.camel@localhost.localdomain> <1113237718.21005.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050411184654.00a5f1cc.bugs.michael@gmx.net> On Mon, 11 Apr 2005 18:41:58 +0200, G?rard Milmeister wrote: > On Mon, 2005-04-11 at 11:01 -0500, Tom 'spot' Callaway wrote: > > All packages described can be found here: > > http://www.auroralinux.org/people/spot/R/ > > > > R is a free software environment for for statistical computing and > > graphics. It is widely used in higher education. It is similar to S, so > > similar, that most S code has been (or can be) ported to R. > > R is very modular, like perl or python. The base R package provides the > > R runtime environment and some core required modules. > > http://www.r-project.org/ > > I had R for some time in my repository: > http://math.ifi.unizh.ch/fedora/3/i386/SRPMS.gemi/R-2.0.1-1.src.rpm > Whenever you bring R into Extras, I can remove it. I say you're the right one to review and sponsor Tom's package. From tcallawa at redhat.com Mon Apr 11 17:09:36 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 12:09:36 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <20050411181839.4e397ca2.bugs.michael@gmx.net> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> Message-ID: <1113239377.5021.74.camel@localhost.localdomain> On Mon, 2005-04-11 at 18:18 +0200, Michael Schwendt wrote: > On Mon, 11 Apr 2005 11:01:16 -0500, Tom 'spot' Callaway wrote: > > > udunits: > > URL: http://my.unidata.ucar.edu/content/software/udunits/index.html > > SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm > > SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec > > For reference: > https://bugzilla.fedora.us/show_bug.cgi?id=921 Thanks! Changes incorporated from that work into my spec, all blockers listed in that bz entry should not apply to my package. udunits-1.12.4-3: http://www.auroralinux.org/people/spot/R/ ~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 Mon Apr 11 17:10:29 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 12:10:29 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <20050411184654.00a5f1cc.bugs.michael@gmx.net> References: <1113235276.5021.62.camel@localhost.localdomain> <1113237718.21005.2.camel@scriabin.tannenrauch.ch> <20050411184654.00a5f1cc.bugs.michael@gmx.net> Message-ID: <1113239430.5021.75.camel@localhost.localdomain> On Mon, 2005-04-11 at 18:46 +0200, Michael Schwendt wrote: > On Mon, 11 Apr 2005 18:41:58 +0200, G?rard Milmeister wrote: > > > On Mon, 2005-04-11 at 11:01 -0500, Tom 'spot' Callaway wrote: > > > All packages described can be found here: > > > http://www.auroralinux.org/people/spot/R/ > > > > > > R is a free software environment for for statistical computing and > > > graphics. It is widely used in higher education. It is similar to S, so > > > similar, that most S code has been (or can be) ported to R. > > > R is very modular, like perl or python. The base R package provides the > > > R runtime environment and some core required modules. > > > http://www.r-project.org/ > > > > I had R for some time in my repository: > > http://math.ifi.unizh.ch/fedora/3/i386/SRPMS.gemi/R-2.0.1-1.src.rpm > > Whenever you bring R into Extras, I can remove it. > > I say you're the right one to review and sponsor Tom's package. You may even be more qualified to own and maintain it than me. :) ~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 Mon Apr 11 17:12:24 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 12:12:24 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113237152.22499.47.camel@bobcat.mine.nu> References: <1113235276.5021.62.camel@localhost.localdomain> <1113237152.22499.47.camel@bobcat.mine.nu> Message-ID: <1113239544.5021.77.camel@localhost.localdomain> On Mon, 2005-04-11 at 19:32 +0300, Ville Skytt? wrote: > On Mon, 2005-04-11 at 11:01 -0500, Tom 'spot' Callaway wrote: > > > perl-Jcode: > > perl-Unicode-Map: > > These are already in Extras. Whoops. Sorry about that, I could have sworn they weren't there when I looked. ~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 thm at duke.edu Mon Apr 11 17:15:57 2005 From: thm at duke.edu (Hunter Matthews) Date: Mon, 11 Apr 2005 13:15:57 -0400 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113235276.5021.62.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> Message-ID: <1113239757.2819.43.camel@jade.biology.duke.edu> On Mon, 2005-04-11 at 12:01, Tom 'spot' Callaway wrote: > > R: > URL: http://www.r-project.org/ > SRPM: http://www.auroralinux.org/people/spot/R/R-2.0.1-8.src.rpm > SPEC: http://www.auroralinux.org/people/spot/R/R.spec > Try the published method for macros in URL's : [thm at jade r]$ rpm -q --specfile R.spec --qf "$(grep -i ^Source R.spec)\n" Source0: ftp://cran.r-project.org/pub/R/src/base/R-2.0.1.tar.gz [thm at jade r]$ wget ftp://cran.r-project.org/pub/R/src/base/R-2.0.1.tar.gz ... Resolving cran.r-project.org... 128.131.51.43 ... ==> PASV ... done. ==> RETR R-2.0.1.tar.gz ... No such file `R-2.0.1.tar.gz'. Other that, the package looks good - the build requires/devel requires make sense, the spec is orderly, no signs of crack. > QuantLib: > URL: http://www.quantlib.org > SRPM: http://www.auroralinux.org/people/spot/R/QuantLib-0.3.8-2.src.rpm > SPEC: http://www.auroralinux.org/people/spot/R/QuantLib.spec > I got an html file instead of hte tarball when using the Source url. I'm also unsure why the %install section cp/mv docs around and then has them as regular package files and not %doc targets. I'm not saying thats wrong, I'm just asking why this instead? I'll review the others as I get more time. Oh - and is there review/qa checklist, cuz I'm just winging this review... -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From wtogami at redhat.com Mon Apr 11 18:24:15 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 11 Apr 2005 08:24:15 -1000 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113239544.5021.77.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> <1113237152.22499.47.camel@bobcat.mine.nu> <1113239544.5021.77.camel@localhost.localdomain> Message-ID: <425AC0CF.9060806@redhat.com> Tom 'spot' Callaway wrote: > On Mon, 2005-04-11 at 19:32 +0300, Ville Skytt? wrote: > >>On Mon, 2005-04-11 at 11:01 -0500, Tom 'spot' Callaway wrote: >> >> >>>perl-Jcode: >>>perl-Unicode-Map: >> >>These are already in Extras. > > > Whoops. Sorry about that, I could have sworn they weren't there when I > looked. http://cvs.fedora.redhat.com/viewcvs/devel/jcode.pl/ And Core! Although tagoh said that we really don't need this in Core anymore. Make sure the Extras perl-Jcode has the Obsoletes and stuff to get rid of it. We'll make sure it is removed from FC4. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Mon Apr 11 19:07:16 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 11 Apr 2005 21:07:16 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113239377.5021.74.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> Message-ID: <20050411210716.2c974e36.bugs.michael@gmx.net> On Mon, 11 Apr 2005 12:09:36 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-11 at 18:18 +0200, Michael Schwendt wrote: > > On Mon, 11 Apr 2005 11:01:16 -0500, Tom 'spot' Callaway wrote: > > > > > udunits: > > > URL: http://my.unidata.ucar.edu/content/software/udunits/index.html > > > SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm > > > SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec > > > > For reference: > > https://bugzilla.fedora.us/show_bug.cgi?id=921 > > Thanks! Changes incorporated from that work into my spec, all blockers > listed in that bz entry should not apply to my package. > > udunits-1.12.4-3: http://www.auroralinux.org/people/spot/R/ Okay. I didn't want to start reviewing this today. But I couldn't resist and clicked the link above for a single brief look. ;) Only the spec is there, the src.rpm is missing. The spec looks much cleaner than the one in fedora.us bugzilla. But the hardcoded Perl vendor install paths, %{_libdir}/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/ are too fragile and should be replaced with %{perl_vendorarch} which is predefined at least since FC3. Whether udunits only installs into vendor paths (and never into site paths) or evaluates the INSTALLSITEARCH=... argument for make install, would be something for a deeper review. From tcallawa at redhat.com Mon Apr 11 19:45:05 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 14:45:05 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <20050411210716.2c974e36.bugs.michael@gmx.net> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> <20050411210716.2c974e36.bugs.michael@gmx.net> Message-ID: <1113248705.5021.89.camel@localhost.localdomain> On Mon, 2005-04-11 at 21:07 +0200, Michael Schwendt wrote: > %{perl_vendorarch} Good point. Fixed in udunits-1.12.4-4: SRPM: http://auroralinux.org/people/spot/R/udunits-1.12.4-4.src.rpm SPEC: http://auroralinux.org/people/spot/R/udunits.spec ~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 gemi at bluewin.ch Mon Apr 11 19:58:29 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 11 Apr 2005 21:58:29 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113239377.5021.74.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> Message-ID: <1113249509.22890.4.camel@scriabin.tannenrauch.ch> On Mon, 2005-04-11 at 12:09 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-11 at 18:18 +0200, Michael Schwendt wrote: > > On Mon, 11 Apr 2005 11:01:16 -0500, Tom 'spot' Callaway wrote: > > > > > udunits: > > > URL: http://my.unidata.ucar.edu/content/software/udunits/index.html > > > SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm > > > SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec > > I looked at your R.spec. It is written for FC4, especially Requires: evince. Could you possibly make it also work for FC3? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From tcallawa at redhat.com Mon Apr 11 20:09:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 15:09:25 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113239757.2819.43.camel@jade.biology.duke.edu> References: <1113235276.5021.62.camel@localhost.localdomain> <1113239757.2819.43.camel@jade.biology.duke.edu> Message-ID: <1113250165.5021.95.camel@localhost.localdomain> On Mon, 2005-04-11 at 13:15 -0400, Hunter Matthews wrote: > No such file `R-2.0.1.tar.gz'. URL fixed in R-2.0.1-9: http://auroralinux.org/people/spot/R/R-2.0.1-9.src.rpm http://auroralinux.org/people/spot/R/R.spec > > QuantLib: > I got an html file instead of hte tarball when using the Source url. Yes, this is because its a sourceforge URL. Hooray for wacky sourceforge. > I'm also unsure why the %install section cp/mv docs around and then has > them as regular package files and not %doc targets. > > I'm not saying thats wrong, I'm just asking why this instead? No, it is wrong. Cleaned up in QuantLib-0.3.8-3: http://auroralinux.org/people/spot/R/QuantLib-0.3.8-3.src.rpm http://auroralinux.org/people/spot/R/QuantLib.spec ~spot From tcallawa at redhat.com Mon Apr 11 20:14:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 15:14:07 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113249509.22890.4.camel@scriabin.tannenrauch.ch> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> <1113249509.22890.4.camel@scriabin.tannenrauch.ch> Message-ID: <1113250447.5021.96.camel@localhost.localdomain> On Mon, 2005-04-11 at 21:58 +0200, G?rard Milmeister wrote: > On Mon, 2005-04-11 at 12:09 -0500, Tom 'spot' Callaway wrote: > > On Mon, 2005-04-11 at 18:18 +0200, Michael Schwendt wrote: > > > On Mon, 11 Apr 2005 11:01:16 -0500, Tom 'spot' Callaway wrote: > > > > > > > udunits: > > > > URL: http://my.unidata.ucar.edu/content/software/udunits/index.html > > > > SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm > > > > SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec > > > > I looked at your R.spec. It is written for FC4, especially Requires: > evince. Could you possibly make it also work for FC3? The only change that the FC3 branch of R would need is to replace the two instances of "evince" with "ggv". ~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 gemi at bluewin.ch Mon Apr 11 20:19:57 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 11 Apr 2005 22:19:57 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113250447.5021.96.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> <1113249509.22890.4.camel@scriabin.tannenrauch.ch> <1113250447.5021.96.camel@localhost.localdomain> Message-ID: <1113250797.23371.0.camel@scriabin.tannenrauch.ch> On Mon, 2005-04-11 at 15:14 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-11 at 21:58 +0200, G?rard Milmeister wrote: > > On Mon, 2005-04-11 at 12:09 -0500, Tom 'spot' Callaway wrote: > > > On Mon, 2005-04-11 at 18:18 +0200, Michael Schwendt wrote: > > > > On Mon, 11 Apr 2005 11:01:16 -0500, Tom 'spot' Callaway wrote: > > > > > > > > > udunits: > > > > > URL: http://my.unidata.ucar.edu/content/software/udunits/index.html > > > > > SRPM: http://www.auroralinux.org/people/spot/R/udunits-1.12.4-2.src.rpm > > > > > SPEC: http://www.auroralinux.org/people/spot/R/udunits.spec > > > > > > I looked at your R.spec. It is written for FC4, especially Requires: > > evince. Could you possibly make it also work for FC3? > > The only change that the FC3 branch of R would need is to replace the > two instances of "evince" with "ggv". Will you import it into Extras and create also a branch for FC3? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From tcallawa at redhat.com Mon Apr 11 20:31:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 15:31:09 -0500 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113250797.23371.0.camel@scriabin.tannenrauch.ch> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> <1113249509.22890.4.camel@scriabin.tannenrauch.ch> <1113250447.5021.96.camel@localhost.localdomain> <1113250797.23371.0.camel@scriabin.tannenrauch.ch> Message-ID: <1113251469.5021.102.camel@localhost.localdomain> On Mon, 2005-04-11 at 22:19 +0200, G?rard Milmeister wrote: > Will you import it into Extras and create also a branch for FC3? Sure, if you're saying 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 bugs.michael at gmx.net Mon Apr 11 21:02:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 11 Apr 2005 23:02:51 +0200 Subject: irssi build failure examined Message-ID: <20050411230251.68faadce.bugs.michael@gmx.net> The new Perl version in FC4 Development introduces a new "config.h" file in /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE, which is included instead of irssi's own config.h file, because the Perl CORE headers path is added via -I/usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE. When I've seen something like that before with a project, an obvious fix was to rename config.h with automake's AM_CONFIG_HEADER macro and avoid the naming conflict. This could be done by irssi upstream, too. Any other ideas? From ivazquez at ivazquez.net Mon Apr 11 21:04:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Apr 2005 17:04:23 -0400 Subject: Request for sponsor: gnet In-Reply-To: <1113236909.5021.70.camel@localhost.localdomain> References: <1112216349.8866.13.camel@ignacio.ignacio.lan> <1112789436.3405.13.camel@ignacio.ignacio.lan> <1113236909.5021.70.camel@localhost.localdomain> Message-ID: <1113253463.5131.16.camel@ignacio.ignacio.lan> On Mon, 2005-04-11 at 11:28 -0500, Tom 'spot' Callaway wrote: > Make those changes, and I'll sponsor its inclusion. Done. http://fedora.ivazquez.net/files/gnet2-2.0.7-2.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 ivazquez at ivazquez.net Mon Apr 11 21:05:10 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Apr 2005 17:05:10 -0400 Subject: Review needed: notecase In-Reply-To: <1113081293.4347.3.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> <1112825276.3405.33.camel@ignacio.ignacio.lan> <1112839017.8621.11.camel@Madison.badger.com> <1113081293.4347.3.camel@Madison.badger.com> Message-ID: <1113253510.5131.17.camel@ignacio.ignacio.lan> On Sat, 2005-04-09 at 17:14 -0400, Toshio wrote: > Let me know when you have another checkin to cvs that you need reviewed. Okay, I added the patch. It builds fine on i386, so go ahead and take a look. -- 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 Apr 11 21:23:57 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Apr 2005 17:23:57 -0400 Subject: Request for Preview: INADYN In-Reply-To: <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> Message-ID: <1113254637.5131.19.camel@ignacio.ignacio.lan> On Mon, 2005-04-11 at 18:15 +0200, Jochen Schmitt wrote: > Corrected version was uploaded to > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm Double up that % in the changelog and I'll sponsor 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 toshio at tiki-lounge.com Mon Apr 11 21:52:54 2005 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 11 Apr 2005 17:52:54 -0400 Subject: Review needed: notecase In-Reply-To: <1113253510.5131.17.camel@ignacio.ignacio.lan> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> <1112825276.3405.33.camel@ignacio.ignacio.lan> <1112839017.8621.11.camel@Madison.badger.com> <1113081293.4347.3.camel@Madison.badger.com> <1113253510.5131.17.camel@ignacio.ignacio.lan> Message-ID: <1113256375.6201.2.camel@Madison.badger.com> On Mon, 2005-04-11 at 17:05 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-04-09 at 17:14 -0400, Toshio wrote: > > Let me know when you have another checkin to cvs that you need reviewed. > > Okay, I added the patch. It builds fine on i386, so go ahead and take a > look. > Looks like this bit from one of my previous patches got left off. It's needed for help to work. -Toshio -- ________S_________U_________B_________L_________I_________M_________E________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: notecasespec2.patch Type: text/x-patch Size: 797 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 tcallawa at redhat.com Mon Apr 11 22:00:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Apr 2005 17:00:39 -0500 Subject: Request for sponsor: gnet In-Reply-To: <1113253463.5131.16.camel@ignacio.ignacio.lan> References: <1112216349.8866.13.camel@ignacio.ignacio.lan> <1112789436.3405.13.camel@ignacio.ignacio.lan> <1113236909.5021.70.camel@localhost.localdomain> <1113253463.5131.16.camel@ignacio.ignacio.lan> Message-ID: <1113256839.5021.106.camel@localhost.localdomain> On Mon, 2005-04-11 at 17:04 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-04-11 at 11:28 -0500, Tom 'spot' Callaway wrote: > > Make those changes, and I'll sponsor its inclusion. > > Done. > > http://fedora.ivazquez.net/files/gnet2-2.0.7-2.src.rpm Great. Import 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 ivazquez at ivazquez.net Mon Apr 11 22:06:56 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Apr 2005 18:06:56 -0400 Subject: Review needed: notecase In-Reply-To: <1113256375.6201.2.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1112816064.5827.9.camel@Madison.badger.com> <1112819438.3405.28.camel@ignacio.ignacio.lan> <1112825276.3405.33.camel@ignacio.ignacio.lan> <1112839017.8621.11.camel@Madison.badger.com> <1113081293.4347.3.camel@Madison.badger.com> <1113253510.5131.17.camel@ignacio.ignacio.lan> <1113256375.6201.2.camel@Madison.badger.com> Message-ID: <1113257217.5131.26.camel@ignacio.ignacio.lan> On Mon, 2005-04-11 at 17:52 -0400, Toshio wrote: > Looks like this bit from one of my previous patches got left off. It's > needed for help to work. D'oh. Fixed. -- 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 gemi at bluewin.ch Mon Apr 11 23:05:52 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 12 Apr 2005 01:05:52 +0200 Subject: Request for Review: R, perl-Jcode, perl-OLE-Storage_Lite, perl-Spreadsheet-WriteExcel, perl-Unicode-Map, QuantLib, udunits In-Reply-To: <1113251469.5021.102.camel@localhost.localdomain> References: <1113235276.5021.62.camel@localhost.localdomain> <20050411181839.4e397ca2.bugs.michael@gmx.net> <1113239377.5021.74.camel@localhost.localdomain> <1113249509.22890.4.camel@scriabin.tannenrauch.ch> <1113250447.5021.96.camel@localhost.localdomain> <1113250797.23371.0.camel@scriabin.tannenrauch.ch> <1113251469.5021.102.camel@localhost.localdomain> Message-ID: <1113260752.9346.1.camel@scriabin.tannenrauch.ch> On Mon, 2005-04-11 at 15:31 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-11 at 22:19 +0200, G?rard Milmeister wrote: > > > Will you import it into Extras and create also a branch for FC3? > > Sure, if you're saying it passes review. :) > > ~spot FC3 will require replacing evince by ggv and gfortran by gcc-g77. Otherwise fine. Is there a reason for not building the gnome/gtk UI? AFAIK the libraries (gnome1) will still be in FC4. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From perbj at stanford.edu Tue Apr 12 02:23:21 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 11 Apr 2005 19:23:21 -0700 Subject: Laptop-mode-tools In-Reply-To: <4258F2F7.30203@redhat.com> References: <1113077285.17730.25.camel@localhost.localdomain> <4258DE0C.8020802@redhat.com> <1113125200.17730.45.camel@localhost.localdomain> <4258F2F7.30203@redhat.com> Message-ID: <1113272602.4682.20.camel@localhost.localdomain> On Sat, 2005-04-09 at 23:33 -1000, Warren Togami wrote: > Hmm with laptop_mode engaged, does it properly sync before going into > suspend? Suspend is often hazardous and it could very easily kill 10 > minutes of data. =) Very good point. As far as I can tell, laptop-mode doesn't do anything in particular at all when the computer is suspending. If there's an explicit sync I think it should do the syncing, otherwise I think your scenario is quite possible. (Not one I thought much about, to be honest, since my notebook stubbornly refuses to wake up from suspend so I have given up on it for now, although I retest it with new kernel versions.) Perhaps it would actually be possible to sync just before actually suspending in the suspend script? I'll check if the upstream maintainer of the laptop-mode tools has any input on this. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From funkyres at gmail.com Tue Apr 12 02:42:10 2005 From: funkyres at gmail.com (Michael Peters) Date: Mon, 11 Apr 2005 19:42:10 -0700 Subject: Looking for a sponsor In-Reply-To: <20050409131120.7157dae4.bugs.michael@gmx.net> References: <485bb88405031617557e855e23@mail.gmail.com> <485bb884050320132825351809@mail.gmail.com> <20050409131120.7157dae4.bugs.michael@gmx.net> Message-ID: <485bb8840504111942610121cb@mail.gmail.com> On Apr 9, 2005 4:11 AM, Michael Schwendt wrote: > > > ERROR 404: Not Found. Yes - I've updated and moved to a small yum repository. http://mpeters.us/sleek/info.html At this point - the only packages needed that are not already in extras are: perl-DBI-SQLite perl-File-BOM perl-Template-Toolkit (and I am aware of other people who may wish to submit it) perl-Text-Autoformat (ditto) perl-File-BOM is a one line pure perl module of very low version number so it might be wiser for it to just include it with slimserver itself. So if the perl-T* are submitted by other contributors, perl-DBI-SQLite would be all that I need in extras for slimserver. The packages are all at http://mpeters.us/sleek/yum/slim/fedora/development/SRPMS/ That list is actually bigger than it should be, since it includes a couple of livna packages (since slimserver is going to be submitted to livna) and some updates to rawhide that are no longer needed, as rawhide has been updated. -- http://mpeters.us/ From ivazquez at ivazquez.net Tue Apr 12 04:28:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 12 Apr 2005 00:28:38 -0400 Subject: Web server MIME types (was: Fedora Extras Development Package Report) In-Reply-To: <1113198903.2813.28.camel@cutter> References: <1113198903.2813.28.camel@cutter> Message-ID: <1113280119.7230.3.camel@ignacio.ignacio.lan> On Mon, 2005-04-11 at 01:55 -0400, seth vidal wrote: > If you see a build error then you should check out the logs located at: > http://fedoraproject.org/extras/development/build-logs/ Files that end in .rpm.log on the server have a MIME type of application/x-rpm, whereas files that end in just .log have a MIME type of text/plain. Who do I speak to about having them both return text/plain so that both types are viewable in the browser instead of having Firefox want to open/save the .rpm.log files locally? BTW, well done Seth, hope you're feeling better. -- 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 luya at jpopmail.com Tue Apr 12 07:27:12 2005 From: luya at jpopmail.com (luya at jpopmail.com) Date: Mon, 11 Apr 2005 23:27:12 -0800 Subject: About submitted updated Blender package Message-ID: <20050412072712.4C4CC23CFF@ws5-3.us4.outblaze.com> Hello, I am looking for sponsor about Blender 2.36.rpm. It is basically an update from 2.35 on which I edit the original spec file found on Fedora Core 3 Extra repository. As I am very new to Wiki, I wonder if there is anyone that can submit Blender 2.36. Thanks. -- _______________________________________________ Get your free email from http://mymail.jp.popstarmail.org Powered by Outblaze From bugs.michael at gmx.net Tue Apr 12 09:47:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 11:47:35 +0200 Subject: Looking for a sponsor In-Reply-To: <485bb8840504111942610121cb@mail.gmail.com> References: <485bb88405031617557e855e23@mail.gmail.com> <485bb884050320132825351809@mail.gmail.com> <20050409131120.7157dae4.bugs.michael@gmx.net> <485bb8840504111942610121cb@mail.gmail.com> Message-ID: <20050412114735.46a291cf.bugs.michael@gmx.net> On Mon, 11 Apr 2005 19:42:10 -0700, Michael Peters wrote: > On Apr 9, 2005 4:11 AM, Michael Schwendt wrote: > > > > > ERROR 404: Not Found. > > Yes - I've updated and moved to a small yum repository. > > http://mpeters.us/sleek/info.html > > At this point - the only packages needed that are not already in extras are: > > perl-DBI-SQLite I've posted a review about it some days ago. From bugs.michael at gmx.net Tue Apr 12 09:48:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 11:48:33 +0200 Subject: About submitted updated Blender package In-Reply-To: <20050412072712.4C4CC23CFF@ws5-3.us4.outblaze.com> References: <20050412072712.4C4CC23CFF@ws5-3.us4.outblaze.com> Message-ID: <20050412114833.027afdcf.bugs.michael@gmx.net> On Mon, 11 Apr 2005 23:27:12 -0800, luya at jpopmail.com wrote: > Hello, > > I am looking for sponsor about Blender 2.36.rpm. It is basically an update from 2.35 on which I edit the original spec file found on Fedora Core 3 Extra repository. As I am very new to Wiki, I wonder if there is anyone that can submit Blender 2.36. Thanks. > The current package owner is reachable via http://bugzilla.redhat.com From bugs.michael at gmx.net Tue Apr 12 12:51:23 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 14:51:23 +0200 Subject: Fedora Extras Development Package Report In-Reply-To: <1113198903.2813.28.camel@cutter> References: <1113198903.2813.28.camel@cutter> Message-ID: <20050412145123.223875cc.bugs.michael@gmx.net> On Mon, 11 Apr 2005 01:55:03 -0400, seth vidal wrote: > Hi Everyone, > > This is the report of the big-package-rebuild orchestrated by Michael > Schwendt release bumping everything that hadn't been updated. > > Instead of posting successes I'm just going to post the list of packages > which failed to rebuild. > > See the attached files for the failed package report for each > architecture. > > If you see a build error then you should check out the logs located at: > http://fedoraproject.org/extras/development/build-logs/ > > > I think I got everything that should have been built, built. It's > possible I missed something. I was sick this weekend so in a > fever-dream-induced delirium something might have been futzed up. Many thanks for that, Seth! The number of build failures look a bit better than expected. But there's still a lot to fix for some packagers. I've created a Wiki page for tracking which packages need to be fixed: http://fedoraproject.org/wiki/Extras/FC4RebuildFailures Two questions have come up while visiting a few build failures: > SRPM Error: lvcool What does that mean? lvcool is a chipset specific package for AMD Athlon/Duron processors. It should not fail on i386. > Build Error: gai-pal The build log is missing. From skvidal at phy.duke.edu Tue Apr 12 13:09:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Apr 2005 09:09:13 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <20050412145123.223875cc.bugs.michael@gmx.net> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> Message-ID: <1113311353.3173.46.camel@cutter> > I've created a Wiki page for tracking which packages need to be > fixed: > > http://fedoraproject.org/wiki/Extras/FC4RebuildFailures cool > Two questions have come up while visiting a few build failures: > > > SRPM Error: lvcool it means the 'cvs update ; make srpm' portion of the script failed for some reason. > > Build Error: gai-pal > > The build log is missing. I'll look into it. -sv From fedora at leemhuis.info Tue Apr 12 13:28:30 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 12 Apr 2005 15:28:30 +0200 Subject: Fedora Extras Development Package Report In-Reply-To: <1113311353.3173.46.camel@cutter> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> Message-ID: <1113312510.11490.38.camel@thl.ct.heise.de> Am Dienstag, den 12.04.2005, 09:09 -0400 schrieb seth vidal: > > I've created a Wiki page for tracking which packages need to be > > fixed: > > > > http://fedoraproject.org/wiki/Extras/FC4RebuildFailures > cool Yes and no -- should we move the Build error from http://www.fedoraproject.org/wiki/Extras_2fFC4Status over to the new page to have all in one place? > > Two questions have come up while visiting a few build failures: > > > > > SRPM Error: lvcool > > it means the 'cvs update ; make srpm' portion of the script failed for > some reason. Maybe because a make srpm in devel/lvcool gives [...] error: No compatible architectures found for build on x86_64 (as it should)? ;-) CU thl From skvidal at phy.duke.edu Tue Apr 12 13:34:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Apr 2005 09:34:53 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1113312510.11490.38.camel@thl.ct.heise.de> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> Message-ID: <1113312893.3173.50.camel@cutter> On Tue, 2005-04-12 at 15:28 +0200, Thorsten Leemhuis wrote: > Am Dienstag, den 12.04.2005, 09:09 -0400 schrieb seth vidal: > > > I've created a Wiki page for tracking which packages need to be > > > fixed: > > > > > > http://fedoraproject.org/wiki/Extras/FC4RebuildFailures > > cool > > Yes and no -- should we move the Build error from > > http://www.fedoraproject.org/wiki/Extras_2fFC4Status > > over to the new page to have all in one place? > > > > Two questions have come up while visiting a few build failures: > > > > > > > SRPM Error: lvcool > > > > it means the 'cvs update ; make srpm' portion of the script failed for > > some reason. > > Maybe because a make srpm in devel/lvcool gives > [...] > error: No compatible architectures found for build > > on x86_64 (as it should)? > it also gives that error on i386, too, though. -sv From ghenry at suretecsystems.com Tue Apr 12 13:49:48 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 12 Apr 2005 14:49:48 +0100 (BST) Subject: [Fedora-packaging] Can you review my specfile: rsnapshot.spec In-Reply-To: <20050412154427.031c843d.bugs.michael@gmx.net> References: <52644.193.195.148.66.1113304003.squirrel@webmail.suretecsystems.com> <20050412141839.0eb0a8e7.bugs.michael@gmx.net> <63769.193.195.148.66.1113311138.squirrel@webmail.suretecsystems.com> <20050412154427.031c843d.bugs.michael@gmx.net> Message-ID: <33461.193.195.148.66.1113313788.squirrel@webmail.suretecsystems.com> > On Tue, 12 Apr 2005 14:05:38 +0100 (BST), Gavin Henry wrote: > >> Can you point me to the wiki page that shows how to checkout your own >> module again, I've forgotten. > > http://cvs.fedora.redhat.com/ > > [ > http://cvs.fedora.redhat.com/extras.shtml > http://cvs.fedora.redhat.com/makefile.shtml > ] > > http://fedoraproject.org/wiki/Extras > > > F'up to fedora-extras-list, please. Thanks. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From bugs.michael at gmx.net Tue Apr 12 13:51:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 15:51:20 +0200 Subject: Fedora Extras Development Package Report In-Reply-To: <1113312510.11490.38.camel@thl.ct.heise.de> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> Message-ID: <20050412155120.639ebda3.bugs.michael@gmx.net> On Tue, 12 Apr 2005 15:28:30 +0200, Thorsten Leemhuis wrote: > Am Dienstag, den 12.04.2005, 09:09 -0400 schrieb seth vidal: > > > I've created a Wiki page for tracking which packages need to be > > > fixed: > > > > > > http://fedoraproject.org/wiki/Extras/FC4RebuildFailures > > cool > > Yes and no -- should we move the Build error from > > http://www.fedoraproject.org/wiki/Extras_2fFC4Status > > over to the new page to have all in one place? The one thing I don't like about the current FC4Status and FC3Status pages is that they are sort of "abused" as some kind of bugzilla system, with comments being added somewhere in the middle, which make the page difficult to read. As soon as permanent problems with a package are discovered, either the packager ought to track this problem privately while it is being worked on or a bugzilla ticket ought to be opened. The primary purpose of the FC4RebuildFailures page is only to not lose this list of failed rebuilds, as I suspect that only few of the build problems are in bugzilla already. If any not easy to fix build failure is found, bugzilla would be the right place where to track it. From bugs.michael at gmx.net Tue Apr 12 13:52:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 15:52:26 +0200 Subject: lvcool (was: Re: Fedora Extras Development Package Report) In-Reply-To: <1113312893.3173.50.camel@cutter> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> <1113312893.3173.50.camel@cutter> Message-ID: <20050412155226.51bbf90a.bugs.michael@gmx.net> On Tue, 12 Apr 2005 09:34:53 -0400, seth vidal wrote: > > > > > SRPM Error: lvcool > > > > > > it means the 'cvs update ; make srpm' portion of the script failed for > > > some reason. > > > > Maybe because a make srpm in devel/lvcool gives > > [...] > > error: No compatible architectures found for build > > > > on x86_64 (as it should)? > > > > it also gives that error on i386, too, though. Cannot reproduce. From skvidal at phy.duke.edu Tue Apr 12 14:13:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Apr 2005 10:13:49 -0400 Subject: lvcool (was: Re: Fedora Extras Development Package Report) In-Reply-To: <20050412155226.51bbf90a.bugs.michael@gmx.net> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> <1113312893.3173.50.camel@cutter> <20050412155226.51bbf90a.bugs.michael@gmx.net> Message-ID: <1113315229.3173.52.camel@cutter> > > > > it also gives that error on i386, too, though. > > Cannot reproduce. > I can. on a p3-1ghz. make srpm creates the same error message. -sv From bugs.michael at gmx.net Tue Apr 12 14:56:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 16:56:50 +0200 Subject: lvcool (was: Re: Fedora Extras Development Package Report) In-Reply-To: <1113315229.3173.52.camel@cutter> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> <1113312893.3173.50.camel@cutter> <20050412155226.51bbf90a.bugs.michael@gmx.net> <1113315229.3173.52.camel@cutter> Message-ID: <20050412165650.6b093d35.bugs.michael@gmx.net> On Tue, 12 Apr 2005 10:13:49 -0400, seth vidal wrote: > > > > > > it also gives that error on i386, too, though. > > > > Cannot reproduce. > > > > I can. > > on a p3-1ghz. > > make srpm creates the same error message. It doesn't like "BuildArch: athlon". Back to i386... From mricon at gmail.com Tue Apr 12 15:08:50 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 12 Apr 2005 11:08:50 -0400 Subject: Suggestion: Verbiste Message-ID: Hello, all: I would like to package and submit Verbiste, a very useful tool for conjugating French verbs. I've used it extensively in the past, and think that lots of people will benefit from having it available (including native speakers, too.;)). Anyone have any objections? Description: Verbiste is a French conjugation system. It contains a C++ library, two programs that can be run from the command line or from another program, and a GNOME applet. This applet shows a text field in the GNOME Panel where the user can enter a conjugated verb and obtain its complete conjugation. The knowledge base is represented in XML and contains over 6800 verbs. Url: http://www3.sympatico.ca/sarrazip/dev/verbiste.html Regards, -- Konstantin Ryabitsev Zlotniks, INC From nphilipp at redhat.com Tue Apr 12 15:41:58 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 12 Apr 2005 17:41:58 +0200 Subject: Suggestion: Verbiste In-Reply-To: References: Message-ID: <1113320518.18083.26.camel@wombat.tiptoe.de> On Tue, 2005-04-12 at 11:08 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > I would like to package and submit Verbiste, a very useful tool for > conjugating French verbs. I've used it extensively in the past, and > think that lots of people will benefit from having it available > (including native speakers, too.;)). > > Anyone have any objections? > > Description: > Verbiste is a French conjugation system. It contains a C++ library, > two programs that can be run from the command line or from another > program, and a GNOME applet. This applet shows a text field in the > GNOME Panel where the user can enter a conjugated verb and obtain its > complete conjugation. The knowledge base is represented in XML and > contains over 6800 verbs. > > Url: > http://www3.sympatico.ca/sarrazip/dev/verbiste.html I'll sponsor you on 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 ville.skytta at iki.fi Tue Apr 12 15:44:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 12 Apr 2005 18:44:25 +0300 Subject: perl-Jcode and jcode.pl (was: Re: Request for Review: R, perl-Jcode, ...) In-Reply-To: <425AC0CF.9060806@redhat.com> References: <1113235276.5021.62.camel@localhost.localdomain> <1113237152.22499.47.camel@bobcat.mine.nu> <1113239544.5021.77.camel@localhost.localdomain> <425AC0CF.9060806@redhat.com> Message-ID: <1113320665.1972.18.camel@bobcat.mine.nu> On Mon, 2005-04-11 at 08:24 -1000, Warren Togami wrote: > Although tagoh said that we really don't need this in Core anymore. > Make sure the Extras perl-Jcode has the Obsoletes and stuff to get rid > of it. We'll make sure it is removed from FC4. Hmm. Although perl-Jcode is most likely a successor to jcode.pl, they're not plug-and-play-interchangeable. So I'm somewhat wary of placing such Obsoletes/Provides, especially since IIRC there are no conflicts between the two. But perl-Jcode is Aurelien's domain and jcode.pl tagoh's... From Jochen at herr-schmitt.de Tue Apr 12 16:06:33 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 12 Apr 2005 18:06:33 +0200 Subject: Request for Preview: INADYN In-Reply-To: <1113254637.5131.19.camel@ignacio.ignacio.lan> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> <1113254637.5131.19.camel@ignacio.ignacio.lan> Message-ID: On Mon, 11 Apr 2005 17:23:57 -0400, you wrote: >On Mon, 2005-04-11 at 18:15 +0200, Jochen Schmitt wrote: >> Corrected version was uploaded to >> >> http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm > >Double up that % in the changelog and I'll sponsor it. I have uploaded the corrected version to: http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-4.src.rpm Best Regards: Jochen Schmitt From jeff at ocjtech.us Tue Apr 12 17:00:47 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 12 Apr 2005 12:00:47 -0500 Subject: Fedora Extras Development Package Report In-Reply-To: <20050412155120.639ebda3.bugs.michael@gmx.net> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> <20050412155120.639ebda3.bugs.michael@gmx.net> Message-ID: <1113325247.4100.4.camel@lt16586.campus.dmacc.edu> On Tue, 2005-04-12 at 15:51 +0200, Michael Schwendt wrote: > > The one thing I don't like about the current FC4Status and FC3Status pages > is that they are sort of "abused" as some kind of bugzilla system, with > comments being added somewhere in the middle, which make the page > difficult to read. > > [...] > > If any not easy to fix build failure is found, bugzilla would be the right > place where to track it. Perhaps the mythical automatic build system needs to automatically create a bugzilla entry and attach the build log if a build failed. Jeff Ollie -------------- 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 Tue Apr 12 17:06:53 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 12 Apr 2005 10:06:53 -0700 Subject: Laptop-mode-tools In-Reply-To: <1113272602.4682.20.camel@localhost.localdomain> References: <1113077285.17730.25.camel@localhost.localdomain> <4258DE0C.8020802@redhat.com> <1113125200.17730.45.camel@localhost.localdomain> <4258F2F7.30203@redhat.com> <1113272602.4682.20.camel@localhost.localdomain> Message-ID: <1113325614.4704.19.camel@localhost.localdomain> On Mon, 2005-04-11 at 19:23 -0700, Per Bjornsson wrote: > I'll check if the upstream maintainer of the laptop-mode tools has any > input on this. Indeed, he says that the laptop-mode-tools scripts could leave you with dirty write buffers, but a simple "sync" should fix that up. He also said that while the time frame is much shorter, you in principle have the same problem even without laptop mode, so a "sync" in the suspend script might not be a bad idea? Any input on this? /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From bugs.michael at gmx.net Tue Apr 12 17:26:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 19:26:52 +0200 Subject: Fedora Extras Development Package Report In-Reply-To: <1113325247.4100.4.camel@lt16586.campus.dmacc.edu> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> <20050412155120.639ebda3.bugs.michael@gmx.net> <1113325247.4100.4.camel@lt16586.campus.dmacc.edu> Message-ID: <20050412192652.48ce6977.bugs.michael@gmx.net> On Tue, 12 Apr 2005 12:00:47 -0500, Jeffrey C. Ollie wrote: > On Tue, 2005-04-12 at 15:51 +0200, Michael Schwendt wrote: > > > > The one thing I don't like about the current FC4Status and FC3Status pages > > is that they are sort of "abused" as some kind of bugzilla system, with > > comments being added somewhere in the middle, which make the page > > difficult to read. > > > > [...] > > > > If any not easy to fix build failure is found, bugzilla would be the right > > place where to track it. > > Perhaps the mythical automatic build system needs to automatically > create a bugzilla entry and attach the build log if a build failed. No. Returning build failure logs to the person, who requested a build, would be sufficient. That would make trial-and-error builds possible - but we don't do these until automated builds are available. Getting assigned an automated bugzilla ticket for every failed build, would increase bugzilla maintenance overhead. Preferably, every build/rebuild is requested by a human-being and every package has at least one developer taking care of it and keeping it prepared during the Fedora Core Test Release cycle. From jfontain at free.fr Tue Apr 12 18:25:38 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 12 Apr 2005 20:25:38 +0200 Subject: Suggestion: Verbiste In-Reply-To: References: Message-ID: <425C12A2.9050800@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin Ryabitsev wrote: > Hello, all: > > I would like to package and submit Verbiste, a very useful tool for > conjugating French verbs. I've used it extensively in the past, > and think that lots of people will benefit from having it available > (including native speakers, too.;)). > > Anyone have any objections? Absolutely not. You have my full support! Let me know if you need help. Jean-Luc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCXBKikG/MMvcT1qQRAowgAJ4u4FzzzyRbUF3H8TfQAbRlcT7juwCgusgS T76+4sBd+jUkr3EenzI1jAc= =zSva -----END PGP SIGNATURE----- From mricon at gmail.com Tue Apr 12 18:43:22 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 12 Apr 2005 14:43:22 -0400 Subject: Preview: Verbiste In-Reply-To: <425C12A2.9050800@free.fr> References: <425C12A2.9050800@free.fr> Message-ID: Hello, all: I've created the packages for verbiste. There is one thing that concerns me: the "make install" step installs files into /usr/share/verbiste-0.1 and into /usr/include/verbiste-0.1. Is having a "0.1" in the directory name a problem? It can probably be patched out, but at the cost of diverging from the upstream. To my knowledge this doesn't really affect anything, just is kinda silly. http://phy.duke.edu/~icon/misc/fedora-extras/verbiste-0.1.10-1.src.rpm http://phy.duke.edu/~icon/misc/fedora-extras/verbiste.spec Regards, -- Konstantin Ryabitsev Zlotniks, INC From ivazquez at ivazquez.net Tue Apr 12 19:04:10 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 12 Apr 2005 15:04:10 -0400 Subject: Preview: Verbiste In-Reply-To: References: <425C12A2.9050800@free.fr> Message-ID: <1113332650.7230.7.camel@ignacio.ignacio.lan> On Tue, 2005-04-12 at 14:43 -0400, Konstantin Ryabitsev wrote: > I've created the packages for verbiste. There is one thing that > concerns me: the "make install" step installs files into > /usr/share/verbiste-0.1 and into /usr/include/verbiste-0.1. Is having > a "0.1" in the directory name a problem? It can probably be patched > out, but at the cost of diverging from the upstream. To my knowledge > this doesn't really affect anything, just is kinda silly. Meh. I guess it depends on how much API breakage is expected. Its .pc file does handle the include dir naming though. > http://phy.duke.edu/~icon/misc/fedora-extras/verbiste-0.1.10-1.src.rpm > http://phy.duke.edu/~icon/misc/fedora-extras/verbiste.spec - Doesn't use %find_lang - Needs "Requires: libxml2-devel" on -devel -- 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 Tue Apr 12 19:56:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Apr 2005 15:56:56 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1113325247.4100.4.camel@lt16586.campus.dmacc.edu> References: <1113198903.2813.28.camel@cutter> <20050412145123.223875cc.bugs.michael@gmx.net> <1113311353.3173.46.camel@cutter> <1113312510.11490.38.camel@thl.ct.heise.de> <20050412155120.639ebda3.bugs.michael@gmx.net> <1113325247.4100.4.camel@lt16586.campus.dmacc.edu> Message-ID: <1113335816.3173.69.camel@cutter> > Perhaps the mythical automatic build system needs to automatically > create a bugzilla entry and attach the build log if a build failed. > The guy working on the mythical automatic build system (me) got sick last week. That's the reason for lack of progress. However, I still got some more work done on it this weekend. I'll post what I've got working this week. It's not complete but I'll check it into cvs and other folks can smack me around about it, okay? -sv From funkyres at gmail.com Tue Apr 12 20:48:11 2005 From: funkyres at gmail.com (Michael Peters) Date: Tue, 12 Apr 2005 13:48:11 -0700 Subject: Review: perl-DBD-SQLite (was: Re: Looking for a sponsor) In-Reply-To: <20050406002947.60979abf.bugs.michael@gmx.net> References: <485bb88405031617557e855e23@mail.gmail.com> <485bb884050320132825351809@mail.gmail.com> <20050406002947.60979abf.bugs.michael@gmx.net> Message-ID: <485bb884050412134844edbc21@mail.gmail.com> On Apr 5, 2005 3:29 PM, Michael Schwendt wrote: > On Sun, 20 Mar 2005 13:28:45 -0800, Michael Peters wrote: > > > I'm still looking for a sponsor. > > I think slimserver needs to go into livna - but there are some perl > > modules that it needs that will need to be available in extras. > > > > At this point I've packaged three of them (only tested in fc4t1) > > > In future I will also be needing perl-DBD-SQLite (I have a spec file > > for it but I have not tested the package with slimserver yet) > > > I'm willing to maintain these perl modules so I can get slimserver > > into livna - so a sponsor would be appreciated. Feedback on the perl > > package spec files would also be appreciated. > > I've had a look at your perl-DBD-SQLite package and found the following: > > * Try to stay very close to the Fedora spectemplate for Perl packages > as found in the fedora-rpmdevtools package in /usr/share/fedora/. > Basically it's the result of what we've come up at fedora.us during > Perl package QA and always finding the same packaging problems in > Perl packages. As attached patch demonstrates, you should be able > to take over the template for your package and also avoid things like > overriding RPM's internal dependency generator or compressing manual > pages yourself. The spec template also ensures that installed files > (in particular DSOs) are writable and can be stripped automatically. > > * Missing directories: avoid creating file lists for the %files section. > Often you need extra "find" expressions for missing %dir entries. > Instead, include files via %perl_vendorarch or %perl_vendorlib which > are the arch-specific/arch-independent root directories for Perl > modules. Missing directories can be created with insufficient file > access permissions depending on umask. > > * Missing perl :MODULE_COMPAT dependency, because it installs into > Perl vendor locations. Fedora spec template has an example. > > * Avoid appearance of buildroot paths in the %build section. Buildroot > should never get the chance to make it into compiled files. Specify > buildroot paths in the %install section only. > > * /usr = %_prefix > > * Package builds without $RPM_OPT_FLAGS and hence creates a useless > debuginfo package. "make OPTIMIZEFLAGS=$RPM_OPT_FLAGS" from Fedora > spectemplate fixes that, too. > > * Move "make test" into the %check spec file section, so it could be > disabled at build-time. Example in patch below. > > * Avoid setting the "Packager" line in the spec file, since you don't > want your name appear in broken binary packages built by somebody > else. Define the packager in your rpmrc. > > --- perl-DBD-SQLite.spec.old 2005-03-22 04:30:40.000000000 +0100 > +++ perl-DBD-SQLite.spec 2005-04-06 00:15:01.000000000 +0200 > @@ -1,19 +1,16 @@ > -%define _use_internal_dependency_generator 0 > - > %define real_name DBD-SQLite > -%define name perl-%{real_name} > > Summary: Self Contained RDBMS in a DBI Driver > -Name: %{name} > +Name: perl-%{real_name} > Version: 1.08 > -Release: 0.0.yjl.0.testing.2 > +Release: 1 > License: GPL or Artistic > Group: System Environment/Libraries > -Source: ftp://ftp.cpan.org/pub/CPAN/modules/by-module/DBD/%{real_name}-%{version}.tar.gz > +Source0: ftp://ftp.cpan.org/pub/CPAN/modules/by-module/DBD/%{real_name}-%{version}.tar.gz > Url: http://search.cpan.org/~msergeant/DBD-SQLite-%{version}/ > -Packager: Michael A. Peters > BuildRoot: %{_tmppath}/%{name}-buildroot/ > BuildRequires: perl-DBI > +Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) > > %description > SQLite is a public domain RDBMS database engine that you can find at > @@ -28,32 +25,28 @@ > %setup -q -n %{real_name}-%{version} > > %build > -CFLAGS="$RPM_OPT_FLAGS" perl Makefile.PL PREFIX=$RPM_BUILD_ROOT/usr INSTALLDIRS=vendor < /dev/null > -make > +CFLAGS="$RPM_OPT_FLAGS" perl Makefile.PL PREFIX=%{_prefix} INSTALLDIRS=vendor < /dev/null > +make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS" > + > +%check || : > make test > > %install > rm -rf $RPM_BUILD_ROOT > -make install > - > -[ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress > - > -find $RPM_BUILD_ROOT \( -name perllocal.pod -o -name .packlist \) -exec rm -v {} \; > - > -find $RPM_BUILD_ROOT/usr -type f -print | > - sed "s@^$RPM_BUILD_ROOT@@g" | > - grep -v perllocal.pod | > - grep -v "\.packlist" > %{name}-%{version}-filelist > -if [ "$(cat %{name}-%{version}-filelist)X" = "X" ] ; then > - echo "ERROR: EMPTY FILE LIST" > - exit -1 > -fi > +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/* > > %clean > rm -rf $RPM_BUILD_ROOT > > -%files -f %{name}-%{version}-filelist > - > +%files > +%defattr(-,root,root,-) > +%{perl_vendorarch}/DBD/ > +%{perl_vendorarch}/auto/DBD/ > +%{_mandir}/man3/* > > %changelog > * Sun Mar 13 2005 Michael A. Peters > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > Thank you - I will fix it. -- http://mpeters.us/ From mattdm at mattdm.org Tue Apr 12 20:55:06 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 16:55:06 -0400 Subject: wxPython In-Reply-To: <1113232631.30988.0.camel@localhost.localdomain> References: <1112658666.6360.64.camel@localhost.localdomain> <1112673280.3613.7.camel@rydia.hardsun.net> <1112694150.6360.68.camel@localhost.localdomain> <20050411150055.GA11785@jadzia.bu.edu> <1113232631.30988.0.camel@localhost.localdomain> Message-ID: <20050412205506.GA1145@jadzia.bu.edu> On Mon, Apr 11, 2005 at 06:17:11PM +0300, Panu Matilainen wrote: > > It would also be nice if it were made to build against the upstream wxGTK > > package, rather than including its own. (I think this should be a goal for > > wxPython 2.6.... > That's exactly how the current wxPython in extras is built. Oh. Good then. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wtogami at redhat.com Tue Apr 12 21:33:07 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 12 Apr 2005 11:33:07 -1000 Subject: perl-Jcode and jcode.pl In-Reply-To: <1113320665.1972.18.camel@bobcat.mine.nu> References: <1113235276.5021.62.camel@localhost.localdomain> <1113237152.22499.47.camel@bobcat.mine.nu> <1113239544.5021.77.camel@localhost.localdomain> <425AC0CF.9060806@redhat.com> <1113320665.1972.18.camel@bobcat.mine.nu> Message-ID: <425C3E93.3030404@redhat.com> Ville Skytt? wrote: > On Mon, 2005-04-11 at 08:24 -1000, Warren Togami wrote: > > >>Although tagoh said that we really don't need this in Core anymore. >>Make sure the Extras perl-Jcode has the Obsoletes and stuff to get rid >>of it. We'll make sure it is removed from FC4. > > > Hmm. Although perl-Jcode is most likely a successor to jcode.pl, > they're not plug-and-play-interchangeable. So I'm somewhat wary of > placing such Obsoletes/Provides, especially since IIRC there are no > conflicts between the two. But perl-Jcode is Aurelien's domain and > jcode.pl tagoh's... > OK thanks. Then tagoh should put jcode.pl into Extras. Warren From bugs.michael at gmx.net Tue Apr 12 21:43:43 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Apr 2005 23:43:43 +0200 Subject: Preview: Verbiste In-Reply-To: References: <425C12A2.9050800@free.fr> Message-ID: <20050412234343.6e9c14ed.bugs.michael@gmx.net> On Tue, 12 Apr 2005 14:43:22 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > I've created the packages for verbiste. There is one thing that > concerns me: the "make install" step installs files into > /usr/share/verbiste-0.1 and into /usr/include/verbiste-0.1. Is having > a "0.1" in the directory name a problem? It can probably be patched > out, but at the cost of diverging from the upstream. To my knowledge > this doesn't really affect anything, just is kinda silly. > > http://phy.duke.edu/~icon/misc/fedora-extras/verbiste-0.1.10-1.src.rpm > http://phy.duke.edu/~icon/misc/fedora-extras/verbiste.spec %package devel Summary: C++ development files for the Verbiste library Group: Development/Libraries Requires: %{name} = %{version}, libxml2-devel Requires: %name = %{version}-%{release} would be safer and ensure that -devel package and main package are really always in sync (which is a good thing because the -devel package defines an API and depends on the main package). From mattdm at mattdm.org Tue Apr 12 21:59:04 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Apr 2005 17:59:04 -0400 Subject: new soap python packages: python-ZSI, python-SOAPpy, python-fpconst Message-ID: <20050412215904.GA3098@jadzia.bu.edu> Must... start... actually... contributing... instead... of... just... talk. So, as I mentioned a few weeks ago, I had to experiment with some SOAP stuff recently, and discovered that the perl SOAP module gets one deep, deep into the CPAN dependency abyss. So, I thought, Certain People are always berating me about not using python, so why don't I check that out. Turned out to be pretty easy. There's about half a dozen Python soap implementations out there, but the two best (entirely different) come from pywebsvcs.sf.net. They are ZSI (Zolera SOAP Infrastructure) and SOAPpy. (And SOAPpy requires fpconst.) python-ZSI: ZSI, the Zolera SOAP Infrastructure, is a pure-Python module that provides an implementation of SOAP messaging, as described in SOAP 1.1 Specification (see http://www.w3.org/TR/soap). It can also be used to build applications using SOAP Messages with Attachments (see http://www.w3.org/TR/SOAP-attachments). ZSI is intended to make it easier to write web services in Python. In particular, ZSI parses and generates SOAP messages, and converts between native Python datatypes and SOAP syntax. Simple dispatch and invocation methods are supported. There are no known bugs. Its only known limitation is that it cannot handle multi-dimensional arrays. python-SOAPpy: SOAPpy provides tools for building SOAP clients and servers. The goal of the SOAPpy team is to provide a full-featured SOAP library for Python that is very simple to use and that fully supports dynamic interaction between clients and servers. python-fpconst: This python module implements constants and functions for working with IEEE754 double-precision special values. It provides constants for Not-a-Number (NaN), Positive Infinity (PosInf), and Negative Infinity (NegInf), as well as functions to test for these values. SRPMS, RPMS, and spec files at: Any comments? Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From byte at aeon.com.my Tue Apr 12 21:58:28 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 13 Apr 2005 07:58:28 +1000 Subject: Web server MIME types (was: Fedora Extras Development Package Report) In-Reply-To: <1113280119.7230.3.camel@ignacio.ignacio.lan> References: <1113198903.2813.28.camel@cutter> <1113280119.7230.3.camel@ignacio.ignacio.lan> Message-ID: <1113343109.4917.394.camel@arena.soho.bytebot.net> On Tue, 2005-04-12 at 00:28 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-04-11 at 01:55 -0400, seth vidal wrote: > > If you see a build error then you should check out the logs located at: > > http://fedoraproject.org/extras/development/build-logs/ > > Files that end in .rpm.log on the server have a MIME type of > application/x-rpm, whereas files that end in just .log have a MIME type > of text/plain. Who do I speak to about having them both return > text/plain so that both types are viewable in the browser instead of > having Firefox want to open/save the .rpm.log files locally? But whats good is that .rpm.log doesn't really need to get read - those are build successes :) The .log stuff is important, as those are packages that need fixing Alas, I'm sure that the mime-types on fedoraproject.org can be changed, but what about the mirror servers that mirror Extras? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From byte at aeon.com.my Wed Apr 13 01:33:16 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 13 Apr 2005 11:33:16 +1000 Subject: FC4 Status and the addition of PPC arch Message-ID: <1113355996.16486.2.camel@arena.soho.bytebot.net> Hi Extras contributors/maintainers, This is in reference to: http://fedoraproject.org/wiki/Extras_2fFC4Status I understand that a lot of you might not realise that we have PPC Extras for FC4 Development branch currently, and it would be great if ya'll didn't forget that So, as opposed to currently just writing: (i386, x86_64) Why not try: (i386, x86_64, ppc) This will at least enable us PPC folk to go in and take a stab at fixing bugs in your packages, and it also gives varied testing to your packages on an architecture of different endianess. Thanks -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From jeff at ocjtech.us Wed Apr 13 04:03:43 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 12 Apr 2005 23:03:43 -0500 Subject: Request for Review: Bazaar-NG (and need a sponsor) Message-ID: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> Since there is a renewed interest in source code management systems, I thought that it would be appropriate to include some more of the alternative SCMs in Fedora Extras. That will definitely make it easier for people to evaluate which SCM they would like to use for their own use, as well as make it easier for people to participate in the development of projects that don't use CVS or Subversion. Ultimately, I'd like to see most of the SCMs with Fedora Extra-compatible licences included. However, I thought that I'd start with Bazaar-NG: URL: http://bazaar-ng.org/ SRPM: http://www.ocjtech.us/bzr-0.0.3-0.1.src.rpm SPEC: http://www.ocjtech.us/bzr.spec It has a dependency on python-elementtree, which AFAICS is in CVS for FC3 extras but has not been built yet. Jeff Ollie -------------- 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 mattdm at mattdm.org Wed Apr 13 04:11:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Apr 2005 00:11:39 -0400 Subject: Request for Review: Bazaar-NG (and need a sponsor) In-Reply-To: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> References: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> Message-ID: <20050413041139.GA21238@jadzia.bu.edu> On Tue, Apr 12, 2005 at 11:03:43PM -0500, Jeffrey C. Ollie wrote: > It has a dependency on python-elementtree, which AFAICS is in CVS for > FC3 extras but has not been built yet. It's in the development tree for Core (and presumably in the FC4 test releases, but I have to admit that I'm too swamped to have even looked at those). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jeff at ocjtech.us Wed Apr 13 04:22:08 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 12 Apr 2005 23:22:08 -0500 Subject: Request for Review: Bazaar-NG (and need a sponsor) In-Reply-To: <20050413041139.GA21238@jadzia.bu.edu> References: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> <20050413041139.GA21238@jadzia.bu.edu> Message-ID: <1113366128.3722.23.camel@lt16586.campus.dmacc.edu> On Wed, 2005-04-13 at 00:11 -0400, Matthew Miller wrote: > On Tue, Apr 12, 2005 at 11:03:43PM -0500, Jeffrey C. Ollie wrote: > > It has a dependency on python-elementtree, which AFAICS is in CVS for > > FC3 extras but has not been built yet. > > It's in the development tree for Core (and presumably in the FC4 test > releases, but I have to admit that I'm too swamped to have even looked at > those). In fact yum 2.3.2, which was put into rawhide sometime between FC4T1 and FC4T2, depends on python-elementtree. Jeff Ollie -------------- 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 leemhuis.info Wed Apr 13 04:57:24 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Apr 2005 06:57:24 +0200 Subject: FC4 Status and the addition of PPC arch In-Reply-To: <1113355996.16486.2.camel@arena.soho.bytebot.net> References: <1113355996.16486.2.camel@arena.soho.bytebot.net> Message-ID: <1113368244.4360.4.camel@thl.ct.heise.de> Hi * Am Mittwoch, den 13.04.2005, 11:33 +1000 schrieb Colin Charles: > This is in reference to: > http://fedoraproject.org/wiki/Extras_2fFC4Status > > I understand that a lot of you might not realise that we have PPC Extras > for FC4 Development branch currently, and it would be great if ya'll > didn't forget that > > So, as opposed to currently just writing: > > (i386, x86_64) > > Why not try: > > (i386, x86_64, ppc) Why not normally omit the architecture there completely? Then nobody can forget ppc ;-) It seems in 95-98% of the cases the rebuilding was done (and should be done) for all archs supported. For the other 2-5% we simply could write: (only i386) or (noarch) Just my 2 cent... CU thl From skvidal at phy.duke.edu Wed Apr 13 04:59:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Apr 2005 00:59:17 -0400 Subject: FC4 Status and the addition of PPC arch In-Reply-To: <1113368244.4360.4.camel@thl.ct.heise.de> References: <1113355996.16486.2.camel@arena.soho.bytebot.net> <1113368244.4360.4.camel@thl.ct.heise.de> Message-ID: <1113368357.18389.12.camel@cutter> > It seems in 95-98% of the cases the rebuilding was done (and should be > done) for all archs supported. For the other 2-5% we simply could write: > > (only i386) > > or > > (noarch) > noarch == all arches. but in the short run - just list the package name if there is no exclusive arch. and in the long run, it won't matter. -sv From funkyres at gmail.com Wed Apr 13 05:20:02 2005 From: funkyres at gmail.com (Michael Peters) Date: Tue, 12 Apr 2005 22:20:02 -0700 Subject: Review: perl-DBD-SQLite (was: Re: Looking for a sponsor) In-Reply-To: <485bb884050412134844edbc21@mail.gmail.com> References: <485bb88405031617557e855e23@mail.gmail.com> <485bb884050320132825351809@mail.gmail.com> <20050406002947.60979abf.bugs.michael@gmx.net> <485bb884050412134844edbc21@mail.gmail.com> Message-ID: <1113369602.7755.3.camel@fc4t2.mpeters.local> On Tue, 2005-04-12 at 13:48 -0700, Michael Peters wrote: > > Thank you - I will fix it. > I have updated the spec file. OK - not really, I started from scratch using the Fedora template, which I believe solves all of the critiques (and modified my .rpmmacros for the packager tag). http://mpeters.us/fc_extras/perl-DBD-SQLite.spec http://mpeters.us/fc_extras/perl-DBD-SQLite-1.08-1.src.rpm From skvidal at phy.duke.edu Wed Apr 13 05:27:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Apr 2005 01:27:15 -0400 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1112503407.15642.52.camel@localhost.localdomain> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050402192456.A748@mail.harddata.com> <1112503407.15642.52.camel@localhost.localdomain> Message-ID: <1113370036.18389.19.camel@cutter> > Well, right now, yum has a list of packages which are "install-only". We > could add a list of packages that are "upgrade-special". When we make > the rpm changes, we add a new flag, say "-S" (and the corresponding > hooks). Then, any package in the upgrade-special list (which could > include a kernel-module-foo mask) would be handled with the rpm -S > operation. I'm sure the apt and smart folks would be able to adapt to > the new mechanism as well. > > Then, if it doesn't work, instead of trying to figure out which hack > implementation isn't working right, we have one implementation to > troubleshoot: the one in rpm. > > Seth, I'd be very interested in your opinion on this, as it relates to > yum. Sorry for the long delay on this response - I was kinda under the weather and only recently going through the mail backlog. making a new transaction state that handles these things will be the harder part, I think. Let me comment on your original rpm -S mechanism: > - rpm looks for existing packages which match %{name}-%{version} for > each of these pending update packages. > - if found, then compare %{release} with that existing > %{name}-%{version} package > - if %{release} of pending update is greater than existing, then > upgrade ONLY that existing package with same %{name}-%{update} That should say %{name}-%{version},right? And what you really want here is: mark for install the new name-ver package mark for erase the package with the matching n-v-a but older e-v-r Is that right? -sv From adrian at lisas.de Wed Apr 13 07:39:25 2005 From: adrian at lisas.de (Adrian Reber) Date: Wed, 13 Apr 2005 09:39:25 +0200 Subject: brightside and PPC Message-ID: <20050413073925.GA16561@lisas.de> I was just fixing the brightside build errors. I did also test it on PPC and detected, that it doesn't build on PPC. I think it requires acme to build successfully on PPC, but as acme is neither in Core nor in Extras the build fails. I will therefore add ExcludeArch: ppc ppc64 in the spec file. Does this make sense? Adrian From funkyres at gmail.com Wed Apr 13 09:14:34 2005 From: funkyres at gmail.com (Michael Peters) Date: Wed, 13 Apr 2005 02:14:34 -0700 Subject: Request for Review - PyRTF Message-ID: <1113383674.9991.5.camel@fc4t2.mpeters.local> Still waiting for sponsorship - but something I would like to see in extras is gourmet (PyGTK recipe manager, I really like it), which depends upon PyRTF which is currently not in extras or core. The sourceforge status for PyRTF is 4 - Beta Homepage for project - http://pyrtf.sourceforge.net/ My spec file - http://mpeters.us/fc_extras/PyRTF.spec My src.rpm - http://mpeters.us/fc_extras/PyRTF-0.43-1.src.rpm From ivazquez at ivazquez.net Wed Apr 13 09:33:54 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 05:33:54 -0400 Subject: Request for Review - PyRTF In-Reply-To: <1113383674.9991.5.camel@fc4t2.mpeters.local> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> Message-ID: <1113384834.12065.5.camel@ignacio.ignacio.lan> On Wed, 2005-04-13 at 02:14 -0700, Michael Peters wrote: > My spec file - http://mpeters.us/fc_extras/PyRTF.spec ? Source0 should have a complete URL if possible (e.g., http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) - BR should be python, not python-devel - Dir %{python_sitelib}/PyRTF not owned by package - Should have [E:]V-R on every changelog entry -- 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 Apr 13 09:35:31 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 05:35:31 -0400 Subject: Request for Preview: INADYN In-Reply-To: References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> <1113254637.5131.19.camel@ignacio.ignacio.lan> Message-ID: <1113384931.12065.7.camel@ignacio.ignacio.lan> On Tue, 2005-04-12 at 18:06 +0200, Jochen Schmitt wrote: > I have uploaded the corrected version to: > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-4.src.rpm Whoops. A period at the end of the Summary was missed. No worries though, import it then clean it up. -- 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 Wed Apr 13 11:41:20 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 13 Apr 2005 06:41:20 -0500 Subject: Kernel module packages (was - Re: Pre-Review: Asterisk) In-Reply-To: <1113370036.18389.19.camel@cutter> References: <1112418894.5677.20.camel@lt16586.campus.dmacc.edu> <1112452089.5677.61.camel@lt16586.campus.dmacc.edu> <1112465119.15642.16.camel@localhost.localdomain> <20050402151748.A28375@mail.harddata.com> <1112482561.15642.39.camel@localhost.localdomain> <20050402192456.A748@mail.harddata.com> <1112503407.15642.52.camel@localhost.localdomain> <1113370036.18389.19.camel@cutter> Message-ID: <1113392480.4201.8.camel@localhost.localdomain> On Wed, 2005-04-13 at 01:27 -0400, seth vidal wrote: > Let me comment on your original rpm -S mechanism: > > > - rpm looks for existing packages which match %{name}-%{version} for > > each of these pending update packages. > > - if found, then compare %{release} with that existing > > %{name}-%{version} package > > - if %{release} of pending update is greater than existing, then > > upgrade ONLY that existing package with same %{name}-%{update} > > That should say %{name}-%{version},right? > And what you really want here is: > mark for install the new name-ver package > mark for erase the package with the matching n-v-a but older e-v-r > > Is that right? Yes, but they have to be performed in the opposite order. If older e-v-r with matching n-v-a exists, then mark older for erase. Mark for install the new name-ver package. ~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 Wed Apr 13 11:42:31 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 13 Apr 2005 06:42:31 -0500 Subject: brightside and PPC In-Reply-To: <20050413073925.GA16561@lisas.de> References: <20050413073925.GA16561@lisas.de> Message-ID: <1113392552.4201.10.camel@localhost.localdomain> On Wed, 2005-04-13 at 09:39 +0200, Adrian Reber wrote: > I was just fixing the brightside build errors. I did also test it on PPC > and detected, that it doesn't build on PPC. I think it requires acme to > build successfully on PPC, but as acme is neither in Core nor in Extras > the build fails. I will therefore add ExcludeArch: ppc ppc64 in the spec > file. Does this make sense? Or, someone could add acme. :) ~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 symbiont at berlios.de Wed Apr 13 12:56:36 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 13 Apr 2005 20:56:36 +0800 Subject: Request for Review - PyRTF In-Reply-To: <1113384834.12065.5.camel@ignacio.ignacio.lan> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> Message-ID: <200504132056.36365.symbiont@berlios.de> On Wednesday 13 April 2005 17:33, Ignacio Vazquez-Abrams wrote: > ? Source0 should have a complete URL if possible (e.g., > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) We should use URLs that mach can use. This is just a mirror page and does not automatically download the package. Maybe a mirror closest to where the Fedora Extras build system is would be the best. Thoughts? -- -jeff From adrian at lisas.de Wed Apr 13 13:13:06 2005 From: adrian at lisas.de (Adrian Reber) Date: Wed, 13 Apr 2005 15:13:06 +0200 Subject: Request for Review - PyRTF In-Reply-To: <200504132056.36365.symbiont@berlios.de> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <200504132056.36365.symbiont@berlios.de> Message-ID: <20050413131306.GA22125@lisas.de> On Wed, Apr 13, 2005 at 08:56:36PM +0800, Jeff Pitman wrote: > On Wednesday 13 April 2005 17:33, Ignacio Vazquez-Abrams wrote: > > ? Source0 should have a complete URL if possible (e.g., > > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) > > We should use URLs that mach can use. This is just a mirror page and > does not automatically download the package. Maybe a mirror closest to > where the Fedora Extras build system is would be the best. Thoughts? Something like http://dl.sf.net/pyrtf/PyRTF-0.43.tar.gz would be much better. This is not the closest mirror but I don't think that mach actually donwloads the source from the specified URL. Adrian From skvidal at phy.duke.edu Wed Apr 13 13:21:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Apr 2005 09:21:41 -0400 Subject: Request for Review - PyRTF In-Reply-To: <20050413131306.GA22125@lisas.de> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <200504132056.36365.symbiont@berlios.de> <20050413131306.GA22125@lisas.de> Message-ID: <1113398501.18389.44.camel@cutter> On Wed, 2005-04-13 at 15:13 +0200, Adrian Reber wrote: > On Wed, Apr 13, 2005 at 08:56:36PM +0800, Jeff Pitman wrote: > > On Wednesday 13 April 2005 17:33, Ignacio Vazquez-Abrams wrote: > > > ? Source0 should have a complete URL if possible (e.g., > > > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) > > > > We should use URLs that mach can use. This is just a mirror page and > > does not automatically download the package. Maybe a mirror closest to > > where the Fedora Extras build system is would be the best. Thoughts? > > Something like http://dl.sf.net/pyrtf/PyRTF-0.43.tar.gz would be > much better. This is not the closest mirror but I don't think that mach > actually donwloads the source from the specified URL. neither mach nor rpmbuild download the package from the url. -sv From toshio at tiki-lounge.com Wed Apr 13 13:52:23 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 13 Apr 2005 09:52:23 -0400 Subject: Review needed: notecase In-Reply-To: <1112789435.3405.11.camel@ignacio.ignacio.lan> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> Message-ID: <1113400345.20297.7.camel@Madison.badger.com> On Wed, 2005-04-06 at 08:10 -0400, Ignacio Vazquez-Abrams wrote: > notecase: A hierarchical note manager > > NoteCase is a hierarchical note manager (aka. outliner). It helps you > organize your everyday text notes into a single document, with > individual notes placed in the tree-like structure (each note can have > its sub-notes, ...). To ensure your privacy, encrypted document format > is supported, along with standard unencrypted format. Okay -- I've run through every checklist I could find and the only nits left are: 1) desktop file dos not include a GenericName field. Could be added when you call desktop-file-install in the %install. 2) Old recommendation to not mix %patch with %patchN (ie: use Patch0: notecase-.... %patch0 -p1 Instead of Patch: notecase-... %patch -p1) Otherwise I think it's pretty much finished. I'll post approved when GenericName is filled in. SHA1SUMS: 878fcf6a6e26156671c6bced9f29c015b0d1ecb4 notecase-0.8.2_src.zip fcb726bf286f5f9341d043ebd1eaa6e9fb4dd36c notecase-0.8.2-paths.patch 7fe06604be2293e53d68358450d1e491999436b2 notecase-0.8.2-strip- unix2dos.patch 8387038cd8ad804ca9fdcbe42326195d16ca592b notecase-x86_64.patch 1508677d76b6ff10ae4576bc05ede15ce2f8b750 notecase.spec -Toshio -- toshio \ 25th March, 1999: Cold rain in Georgia. Blustery blowing wind. @tiki \ Freezing fingers and tired body. Hiking on because the shelters -lounge \ are filled with other hikers. .com \__________Life is miserable -- Life is grand!_______ GA->ME 1999 -------------- 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 Wed Apr 13 14:26:11 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 13 Apr 2005 16:26:11 +0200 Subject: Request for Preview: INADYN In-Reply-To: <1113384931.12065.7.camel@ignacio.ignacio.lan> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> <1113254637.5131.19.camel@ignacio.ignacio.lan> <1113384931.12065.7.camel@ignacio.ignacio.lan> Message-ID: <0ML25U-1DLiom3mKg-0000mG@mrelayeu.kundenserver.de> On Wed, 13 Apr 2005 05:35:31 -0400, you wrote: >On Tue, 2005-04-12 at 18:06 +0200, Jochen Schmitt wrote: >> I have uploaded the corrected version to: >> >> http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-4.src.rpm > >Whoops. A period at the end of the Summary was missed. No worries >though, import it then clean it up. Can you import the package to CVS, becouse I don't have CVS access. Thank you in advance. Best Regards: Jochen Schmitt From shahms at shahms.com Wed Apr 13 14:55:31 2005 From: shahms at shahms.com (Shahms King) Date: Wed, 13 Apr 2005 07:55:31 -0700 Subject: Whether tis nobler to break backwards compat or upstream compat... Message-ID: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> One of the packages I maintain in Extras (python-quixote) just released the next stable version (2.0). This version is not (entirely) backwards compatible with the current 1.2 version and is not parallel installable. This begs the question of the best practice for packaging such changes. Since it is a relatively recent package, do I just "go for it" and upgrade the devel/FC4 packages, leaving FC3 untouched, or package it as "python-quixote2" (with requisite installation changes) and thus break with upstream? -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- 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 fedoraproject.org Wed Apr 13 15:13:36 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 13 Apr 2005 11:13:36 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1113405216.18389.53.camel@cutter> errors: logjam alsa-tools comical gnome-themes-extras gwenview (i386, x86_64) python-reportlab (x86_64) xmms-alarm (ppc) Otherwise they succeeded. -sv -------------- 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 Wed Apr 13 15:12:52 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 14 Apr 2005 01:12:52 +1000 Subject: brightside and PPC In-Reply-To: <20050413073925.GA16561@lisas.de> References: <20050413073925.GA16561@lisas.de> Message-ID: <1113405173.16486.62.camel@arena.soho.bytebot.net> On Wed, 2005-04-13 at 09:39 +0200, Adrian Reber wrote: > I was just fixing the brightside build errors. I did also test it on PPC > and detected, that it doesn't build on PPC. I think it requires acme to > build successfully on PPC, but as acme is neither in Core nor in Extras > the build fails. I will therefore add ExcludeArch: ppc ppc64 in the spec > file. Does this make sense? Is it not odd that acme is required on ppc/ppc64 but not on the other archs? In fact, acme has been rolled into gnome's control-center since say, 2.6 iirc, so it shouldn't require acme on any arch to make it work -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From notting at redhat.com Wed Apr 13 15:14:25 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Apr 2005 11:14:25 -0400 Subject: Whether tis nobler to break backwards compat or upstream compat... In-Reply-To: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> References: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> Message-ID: <20050413151425.GA26726@nostromo.devel.redhat.com> Shahms King (shahms at shahms.com) said: > One of the packages I maintain in Extras (python-quixote) just released > the next stable version (2.0). This version is not (entirely) backwards > compatible with the current 1.2 version and is not parallel installable. Does anything currently use it that would need ported? Bill From shahms at shahms.com Wed Apr 13 15:18:23 2005 From: shahms at shahms.com (Shahms King) Date: Wed, 13 Apr 2005 08:18:23 -0700 Subject: Whether tis nobler to break backwards compat or upstream compat... In-Reply-To: <20050413151425.GA26726@nostromo.devel.redhat.com> References: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> <20050413151425.GA26726@nostromo.devel.redhat.com> Message-ID: <1113405503.5668.8.camel@shahms.mesd.k12.or.us> On Wed, 2005-04-13 at 11:14 -0400, Bill Nottingham wrote: > Shahms King (shahms at shahms.com) said: > > One of the packages I maintain in Extras (python-quixote) just released > > the next stable version (2.0). This version is not (entirely) backwards > > compatible with the current 1.2 version and is not parallel installable. > > Does anything currently use it that would need ported? > > Bill Nothing in Extras, but it's still a rude thing to do to anyone who was using it ... (but is a relatively new package...) -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- 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 toshio at tiki-lounge.com Wed Apr 13 16:00:12 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 13 Apr 2005 12:00:12 -0400 Subject: Whether tis nobler to break backwards compat or upstream compat... In-Reply-To: <1113405503.5668.8.camel@shahms.mesd.k12.or.us> References: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> <20050413151425.GA26726@nostromo.devel.redhat.com> <1113405503.5668.8.camel@shahms.mesd.k12.or.us> Message-ID: <1113408014.20297.15.camel@Madison.badger.com> On Wed, 2005-04-13 at 08:18 -0700, Shahms King wrote: > On Wed, 2005-04-13 at 11:14 -0400, Bill Nottingham wrote: > > Shahms King (shahms at shahms.com) said: > > > One of the packages I maintain in Extras (python-quixote) just released > > > the next stable version (2.0). This version is not (entirely) backwards > > > compatible with the current 1.2 version and is not parallel installable. > > I think tradition has been to package (2.0) as python-quixote and if someone needed python-quixote-1.x to make a python-quixote1 package unless upstream has made the decision to make things parallel installable (as in gtk2 vs gtk+). Witness the fact that we have php rather than php5 for instance. > > Does anything currently use it that would need ported? > > > > Bill > > Nothing in Extras, but it's still a rude thing to do to anyone who was > using it ... (but is a relatively new package...) Since this was put in so recently (past month, right?) I'd move FC3 and FC4 to python-quixote 2.0. If someone needs quixote-1.2 it can be added as a python-quixote1 package. -Toshio -- _________________ Attraction's easy; love is hard ______________________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 Wed Apr 13 17:00:41 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Apr 2005 19:00:41 +0200 Subject: Whether tis nobler to break backwards compat or upstream compat... In-Reply-To: <1113408014.20297.15.camel@Madison.badger.com> References: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> <20050413151425.GA26726@nostromo.devel.redhat.com> <1113405503.5668.8.camel@shahms.mesd.k12.or.us> <1113408014.20297.15.camel@Madison.badger.com> Message-ID: <1113411641.23020.172.camel@mccallum.corsepiu.local> On Wed, 2005-04-13 at 12:00 -0400, Toshio wrote: > On Wed, 2005-04-13 at 08:18 -0700, Shahms King wrote: > > On Wed, 2005-04-13 at 11:14 -0400, Bill Nottingham wrote: > > > Shahms King (shahms at shahms.com) said: > > > > One of the packages I maintain in Extras (python-quixote) just released > > > > the next stable version (2.0). This version is not (entirely) backwards > > > > compatible with the current 1.2 version and is not parallel installable. > > > > I think tradition has been to package (2.0) as python-quixote and if > someone needed python-quixote-1.x to make a python-quixote1 package This is only possible if both packages can be installed in parallel or if both packages are strictly orthogonal alternatives. Otherwise adding a "backward legacy" package is not possible. > unless upstream has made the decision to make things parallel > installable (as in gtk2 vs gtk+). That's the way "clever" developers should handle cases like this. The Quixote folks not having done so gives an insight about their foresight. > Witness the fact that we have php rather than php5 for instance. In general, this only applicable if (package+1) replaces (package) and if (package+1) is sufficiently compatible to (package). I know to little about php3/php4/php5 to judge if this decision is reasonable wrt. php. > > > Does anything currently use it that would need ported? > > > > > > Bill > > > > Nothing in Extras, but it's still a rude thing to do to anyone who was > > using it ... (but is a relatively new package...) > > Since this was put in so recently (past month, right?) I'd move FC3 and > FC4 to python-quixote 2.0. ACK. > If someone needs quixote-1.2 it can be added > as a python-quixote1 package. As I tried to express above, I doubt this will be possible. Ralf From ville.skytta at iki.fi Wed Apr 13 17:03:12 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 13 Apr 2005 20:03:12 +0300 Subject: Fedora Extras Development Package Report In-Reply-To: <1113405216.18389.53.camel@cutter> References: <1113405216.18389.53.camel@cutter> Message-ID: <1113411792.4759.79.camel@bobcat.mine.nu> On Wed, 2005-04-13 at 11:13 -0400, seth vidal wrote: > xmms-alarm (ppc) No build log in http://fedoraproject.org/extras/development/build-logs/ppc/ Quite a few other build logs from the mass rebuild are missing too, at least from i386 and PPC. PPC section updated at http://fedoraproject.org/wiki/Extras_2fFC4RebuildFailures From bugs.michael at gmx.net Wed Apr 13 17:16:41 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Apr 2005 19:16:41 +0200 Subject: Review needed: notecase In-Reply-To: <1113400345.20297.7.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1113400345.20297.7.camel@Madison.badger.com> Message-ID: <20050413191641.440b5e24.bugs.michael@gmx.net> On Wed, 13 Apr 2005 09:52:23 -0400, Toshio wrote: > 2) Old recommendation to not mix %patch with %patchN (ie: use Patch0: > notecase-.... %patch0 -p1 Instead of Patch: notecase-... %patch -p1) What's the background for this recommendation? What's an example for "problems" caused by mixing %patch with %patchN? From funkyres at gmail.com Wed Apr 13 17:35:38 2005 From: funkyres at gmail.com (Michael Peters) Date: Wed, 13 Apr 2005 10:35:38 -0700 Subject: Request for Review - PyRTF In-Reply-To: <1113384834.12065.5.camel@ignacio.ignacio.lan> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> Message-ID: <1113413738.17039.0.camel@fc4t2.mpeters.local> On Wed, 2005-04-13 at 05:33 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-13 at 02:14 -0700, Michael Peters wrote: > > My spec file - http://mpeters.us/fc_extras/PyRTF.spec > > ? Source0 should have a complete URL if possible (e.g., > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) > - BR should be python, not python-devel > - Dir %{python_sitelib}/PyRTF not owned by package > - Should have [E:]V-R on every changelog entry Thanks - fixed From ivazquez at ivazquez.net Wed Apr 13 18:15:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 14:15:23 -0400 Subject: Request for Review - PyRTF In-Reply-To: <1113413738.17039.0.camel@fc4t2.mpeters.local> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <1113413738.17039.0.camel@fc4t2.mpeters.local> Message-ID: <1113416123.12065.10.camel@ignacio.ignacio.lan> On Wed, 2005-04-13 at 10:35 -0700, Michael Peters wrote: > On Wed, 2005-04-13 at 05:33 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-04-13 at 02:14 -0700, Michael Peters wrote: > > > My spec file - http://mpeters.us/fc_extras/PyRTF.spec > > > > ? Source0 should have a complete URL if possible (e.g., > > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) > > - BR should be python, not python-devel > > - Dir %{python_sitelib}/PyRTF not owned by package > > - Should have [E:]V-R on every changelog entry > > Thanks - fixed You missed the BR. noarch Python packages only need distutils, not the whole includes/libs set. And distutils comes in the base python package. [ignacio at ignacio ~]$ rpm -qf /usr/lib/python2.3/distutils/ python-2.3.4-13.1.i386 -- 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 thm at duke.edu Wed Apr 13 18:32:01 2005 From: thm at duke.edu (Hunter Matthews) Date: Wed, 13 Apr 2005 14:32:01 -0400 Subject: Request for Review: Bazaar-NG (and need a sponsor) In-Reply-To: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> References: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> Message-ID: <1113417121.3028.0.camel@jade.biology.duke.edu> On Wed, 2005-04-13 at 00:03, Jeffrey C. Ollie wrote: > included. However, I thought that I'd start with Bazaar-NG: Is monotone on your list? -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From jeff at ocjtech.us Wed Apr 13 18:45:45 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 13 Apr 2005 13:45:45 -0500 Subject: Request for Review: Bazaar-NG (and need a sponsor) In-Reply-To: <1113417121.3028.0.camel@jade.biology.duke.edu> References: <1113365023.3722.17.camel@lt16586.campus.dmacc.edu> <1113417121.3028.0.camel@jade.biology.duke.edu> Message-ID: <1113417945.4199.37.camel@lt16586.campus.dmacc.edu> On Wed, 2005-04-13 at 14:32 -0400, Hunter Matthews wrote: > On Wed, 2005-04-13 at 00:03, Jeffrey C. Ollie wrote: > > > included. However, I thought that I'd start with Bazaar-NG: > > Is monotone on your list? Yes, I have it 0.18 building on FC3, but it won't build on FC4 yet. I think that I have gotten a solution from someone on the monotone IRC channel but I have yet to try it out. 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 ivazquez at ivazquez.net Wed Apr 13 19:23:20 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 15:23:20 -0400 Subject: CVS Import Error (was: Re: Request for Preview: INADYN) In-Reply-To: <0ML25U-1DLiom3mKg-0000mG@mrelayeu.kundenserver.de> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> <1113254637.5131.19.camel@ignacio.ignacio.lan> <1113384931.12065.7.camel@ignacio.ignacio.lan> <0ML25U-1DLiom3mKg-0000mG@mrelayeu.kundenserver.de> Message-ID: <1113420200.12065.17.camel@ignacio.ignacio.lan> On Wed, 2005-04-13 at 16:26 +0200, Jochen Schmitt wrote: > Can you import the package to CVS, becouse I don't have CVS > access. I tried, but got a nasty set of error messages: [ignacio at ignacio common]$ ./cvs-import.sh ~/work/inadyn-1.90-4.src.rpm Checking out the modules file... Creating new module: inadyn Traceback (most recent call last): File "/cvs/extras/CVSROOT/syncmail", line 301, in ? main() File "/cvs/extras/CVSROOT/syncmail", line 295, in main blast_mail(subject, people) File "/cvs/extras/CVSROOT/syncmail", line 234, in blast_mail fp.write(calculate_diff(file)) IOError: [Errno 32] Broken pipe Running syncmail... Mailing cvsextras... ...syncmail done. Running syncmail... Mailing cvsextras... ...syncmail done. sh: line 1: /usr/sbin/sendmail: No such file or directory sh: line 1: /usr/sbin/sendmail: No such file or directory /cvs/extras/CVSROOT/tag-check: line 1: sed: command not found /cvs/extras/CVSROOT/tag-check: line 1: awk: command not found /cvs/extras/CVSROOT/tag-check: line 1: awk: command not found /cvs/extras/CVSROOT/tag-check: line 1: sed: command not found ERROR: creating module-wide tags is prohibited cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! Entry for module 'inadyn' created. Checking out module: 'inadyn' Unpacking source package: inadyn-1.90-4.src.rpm... A inadyn.conf A inadyn.spec L inadyn.v1.90.zip Checking : inadyn.v1.90.zip on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 736 100 351 100 385 395 433 --:--:-- --:--:-- --:--:-- 3888 Source upload succeeded. Don't forget to commit the new ./sources file M sources M .cvsignore cvs commit... Commit Complete /cvs/extras/CVSROOT/tag-check: line 1: sed: command not found /cvs/extras/CVSROOT/tag-check: line 1: awk: command not found /cvs/extras/CVSROOT/tag-check: line 1: awk: command not found /cvs/extras/CVSROOT/tag-check: line 1: sed: command not found ERROR: Tag inadyn-1_90-4 is not in a valid tag format cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! I did set up things as specified in the "Using your Fedora CVS account" e-mail, so I'm at a complete loss on this one... -- 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 toshio at tiki-lounge.com Wed Apr 13 19:26:58 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 13 Apr 2005 15:26:58 -0400 Subject: Whether tis nobler to break backwards compat or upstream compat... In-Reply-To: <1113411641.23020.172.camel@mccallum.corsepiu.local> References: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> <20050413151425.GA26726@nostromo.devel.redhat.com> <1113405503.5668.8.camel@shahms.mesd.k12.or.us> <1113408014.20297.15.camel@Madison.badger.com> <1113411641.23020.172.camel@mccallum.corsepiu.local> Message-ID: <1113420419.20297.22.camel@Madison.badger.com> On Wed, 2005-04-13 at 19:00 +0200, Ralf Corsepius wrote: > On Wed, 2005-04-13 at 12:00 -0400, Toshio wrote: > > On Wed, 2005-04-13 at 08:18 -0700, Shahms King wrote: > > > On Wed, 2005-04-13 at 11:14 -0400, Bill Nottingham wrote: > > > > Shahms King (shahms at shahms.com) said: > > > > > One of the packages I maintain in Extras (python-quixote) just released > > > > > the next stable version (2.0). This version is not (entirely) backwards > > > > > compatible with the current 1.2 version and is not parallel installable. > > > > > > I think tradition has been to package (2.0) as python-quixote and if > > someone needed python-quixote-1.x to make a python-quixote1 package > This is only possible if both packages can be installed in parallel or > if both packages are strictly orthogonal alternatives. > > Otherwise adding a "backward legacy" package is not possible. > True. What I didn't quote was Shahms's question as to whether he (as packager) should make the python-quixote 2.x package parallel installable with version 1.x. Rather than spend time doing that, it seemed to me that the new version should be installed as is and if there's a need for a 1.x, do the packaging work there to make it parallel install. -Toshio GA->ME 1999 -------------- 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 Wed Apr 13 19:47:07 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 13 Apr 2005 22:47:07 +0300 Subject: CVS Import Error (was: Re: Request for Preview: INADYN) In-Reply-To: <1113420200.12065.17.camel@ignacio.ignacio.lan> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> <1113254637.5131.19.camel@ignacio.ignacio.lan> <1113384931.12065.7.camel@ignacio.ignacio.lan> <0ML25U-1DLiom3mKg-0000mG@mrelayeu.kundenserver.de> <1113420200.12065.17.camel@ignacio.ignacio.lan> Message-ID: <1113421627.4759.116.camel@bobcat.mine.nu> On Wed, 2005-04-13 at 15:23 -0400, Ignacio Vazquez-Abrams wrote: [SNIP] > I did set up things as specified in the "Using your Fedora CVS account" > e-mail, so I'm at a complete loss on this one... I received similar errors, although less of them, when trying out stuff so you're not alone. In particular, all uploads seem to be borked now. (I've already sent details of the errors I received to sopwith.) From jeff at ocjtech.us Wed Apr 13 20:10:09 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 13 Apr 2005 15:10:09 -0500 Subject: Request for Review: monotone Message-ID: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Continuing my quest to get more source code management tools into Fedora Extras, here is monotone. It'll build on FC3, but fails to build on FC4 (probably something related to gcc4). If anyone can get monotone compiling on FC4 I'd appreciate it if you'd let me know. URL: http://www.venge.net/monotone/ SRPM: http://www.ocjtech.us/monotone-0.18-0.1.src.rpm SPEC: http://www.ocjtech.us/monotone.spec Jeff Ollie -------------- 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 shahms at shahms.com Wed Apr 13 20:13:22 2005 From: shahms at shahms.com (Shahms King) Date: Wed, 13 Apr 2005 13:13:22 -0700 Subject: Request for Review: monotone In-Reply-To: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Message-ID: <1113423202.5668.14.camel@shahms.mesd.k12.or.us> On Wed, 2005-04-13 at 15:10 -0500, Jeffrey C. Ollie wrote: > Continuing my quest to get more source code management tools into Fedora > Extras, here is monotone. It'll build on FC3, but fails to build on FC4 > (probably something related to gcc4). If anyone can get monotone > compiling on FC4 I'd appreciate it if you'd let me know. > > URL: http://www.venge.net/monotone/ > SRPM: http://www.ocjtech.us/monotone-0.18-0.1.src.rpm > SPEC: http://www.ocjtech.us/monotone.spec > > Jeff Ollie I'm assuming you have the release as 0.1 because it's an "unofficial" package? Barring that the spec file looks good. I'm trying to build on FC4 now and will let you know more in a bit. -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- 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 Apr 13 20:28:58 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 16:28:58 -0400 Subject: Request for Review: monotone In-Reply-To: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Message-ID: <1113424138.12065.30.camel@ignacio.ignacio.lan> On Wed, 2005-04-13 at 15:10 -0500, Jeffrey C. Ollie wrote: > SPEC: http://www.ocjtech.us/monotone.spec - Doesn't use parallel make - No %post[un] handling of info 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 jeff at ocjtech.us Wed Apr 13 20:36:50 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 13 Apr 2005 15:36:50 -0500 Subject: Request for Review: monotone In-Reply-To: <1113423202.5668.14.camel@shahms.mesd.k12.or.us> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113423202.5668.14.camel@shahms.mesd.k12.or.us> Message-ID: <1113424610.4199.72.camel@lt16586.campus.dmacc.edu> On Wed, 2005-04-13 at 13:13 -0700, Shahms King wrote: > On Wed, 2005-04-13 at 15:10 -0500, Jeffrey C. Ollie wrote: > > Continuing my quest to get more source code management tools into Fedora > > Extras, here is monotone. It'll build on FC3, but fails to build on FC4 > > (probably something related to gcc4). If anyone can get monotone > > compiling on FC4 I'd appreciate it if you'd let me know. > > > > URL: http://www.venge.net/monotone/ > > SRPM: http://www.ocjtech.us/monotone-0.18-0.1.src.rpm > > SPEC: http://www.ocjtech.us/monotone.spec > > I'm assuming you have the release as 0.1 because it's an "unofficial" > package? Whenever I start packaging a new progam/version, I start with 0.1 as the release tag. Once I have the "final" package ready I bump the release to 1. > Barring that the spec file looks good. I'm trying to build on > FC4 now and will let you know more in a bit. Jeff Ollie -------------- 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 toshio at tiki-lounge.com Wed Apr 13 20:37:47 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 13 Apr 2005 16:37:47 -0400 Subject: Review needed: notecase In-Reply-To: <20050413191641.440b5e24.bugs.michael@gmx.net> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1113400345.20297.7.camel@Madison.badger.com> <20050413191641.440b5e24.bugs.michael@gmx.net> Message-ID: <1113424669.20297.36.camel@Madison.badger.com> On Wed, 2005-04-13 at 19:16 +0200, Michael Schwendt wrote: > On Wed, 13 Apr 2005 09:52:23 -0400, Toshio wrote: > > > 2) Old recommendation to not mix %patch with %patchN (ie: use Patch0: > > notecase-.... %patch0 -p1 Instead of Patch: notecase-... %patch -p1) > > What's the background for this recommendation? > > What's an example for "problems" caused by mixing %patch with %patchN? > Disclaimer: I didn't make this a prereq for approval, just noted it. (Unlike #1 which could affect end-user's menus.) It's on the wiki at: http://www.fedoraproject.org/wiki/NewPackageProcess There was some discussion on packaging-list about justification of which this one stuck in my mind: https://www.redhat.com/archives/fedora-packaging/2005- March/msg00045.html -Toshio -- _________________ Move to Mexico! Learn to roll sushi! _________________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 zuirdj at gmail.com Wed Apr 13 20:37:59 2005 From: zuirdj at gmail.com (Zuir DJ) Date: Wed, 13 Apr 2005 16:37:59 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1113405216.18389.53.camel@cutter> References: <1113405216.18389.53.camel@cutter> Message-ID: Thanks. Solved notemeister #152530 bug. Zuirdj On 4/13/05, seth vidal wrote: > errors: > logjam > alsa-tools > comical > gnome-themes-extras > gwenview (i386, x86_64) > python-reportlab (x86_64) > xmms-alarm (ppc) > > Otherwise they succeeded. > -sv > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > From adrian at lisas.de Wed Apr 13 21:07:25 2005 From: adrian at lisas.de (Adrian Reber) Date: Wed, 13 Apr 2005 23:07:25 +0200 Subject: brightside and PPC In-Reply-To: <1113405173.16486.62.camel@arena.soho.bytebot.net> References: <20050413073925.GA16561@lisas.de> <1113405173.16486.62.camel@arena.soho.bytebot.net> Message-ID: <20050413210725.GA14906@lisas.de> On Thu, Apr 14, 2005 at 01:12:52AM +1000, Colin Charles wrote: > On Wed, 2005-04-13 at 09:39 +0200, Adrian Reber wrote: > > I was just fixing the brightside build errors. I did also test it on PPC > > and detected, that it doesn't build on PPC. I think it requires acme to > > build successfully on PPC, but as acme is neither in Core nor in Extras > > the build fails. I will therefore add ExcludeArch: ppc ppc64 in the spec > > file. Does this make sense? > > Is it not odd that acme is required on ppc/ppc64 but not on the other > archs? > > In fact, acme has been rolled into gnome's control-center since say, 2.6 > iirc, so it shouldn't require acme on any arch to make it work I haven' tried it out, it was just a guess that it needs acme. If brightside is compiled on ppc then USE_FBLEVEL is defined which enables code which uses do_brightness_action() and I found that acme provides this function. I had another look at brightside and I think that it doesn't work at all on PPC because another error is that it tries to use code which if commented out with #if 0 ... #endif. As far as I see there are now 2 options. Either the package isn't build at all for PPC or the PPC specific code (mostly it is dim backlight) could be disabled and brightside would offer the same functionality as on i386. Adrian From jeff at ocjtech.us Wed Apr 13 21:28:03 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 13 Apr 2005 16:28:03 -0500 Subject: Request for Review: monotone In-Reply-To: <1113424138.12065.30.camel@ignacio.ignacio.lan> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113424138.12065.30.camel@ignacio.ignacio.lan> Message-ID: <1113427683.4199.84.camel@lt16586.campus.dmacc.edu> On Wed, 2005-04-13 at 16:28 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-13 at 15:10 -0500, Jeffrey C. Ollie wrote: > > SPEC: http://www.ocjtech.us/monotone.spec > > - Doesn't use parallel make > - No %post[un] handling of info files Thanks for the feedback. New versions: URL: http://www.venge.net/monotone/ SRPM: http://www.ocjtech.us/monotone-0.18-0.1.src.rpm SPEC: http://www.ocjtech.us/monotone.spec 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 bugs.michael at gmx.net Wed Apr 13 21:45:15 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Apr 2005 23:45:15 +0200 Subject: Review needed: notecase In-Reply-To: <1113424669.20297.36.camel@Madison.badger.com> References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1113400345.20297.7.camel@Madison.badger.com> <20050413191641.440b5e24.bugs.michael@gmx.net> <1113424669.20297.36.camel@Madison.badger.com> Message-ID: <20050413234515.10c408d2.bugs.michael@gmx.net> On Wed, 13 Apr 2005 16:37:47 -0400, Toshio wrote: > On Wed, 2005-04-13 at 19:16 +0200, Michael Schwendt wrote: > > On Wed, 13 Apr 2005 09:52:23 -0400, Toshio wrote: > > > > > 2) Old recommendation to not mix %patch with %patchN (ie: use Patch0: > > > notecase-.... %patch0 -p1 Instead of Patch: notecase-... %patch -p1) > > > > What's the background for this recommendation? > > > > What's an example for "problems" caused by mixing %patch with %patchN? > > > Disclaimer: I didn't make this a prereq for approval, just noted it. > (Unlike #1 which could affect end-user's menus.) > > It's on the wiki at: http://www.fedoraproject.org/wiki/NewPackageProcess > > There was some discussion on packaging-list about justification of which > this one stuck in my mind: > https://www.redhat.com/archives/fedora-packaging/2005-March/msg00045.html Oh, I even participated in that thread. ;) Okay, okay, so it's just stylistic nitpicking and requires packagers to change something into something else which doesn't improve the package. I think we've yet to see a package where somebody really tries Patch: foo.patch Patch: bar.patch %patch -b .foo %patch -b .bar and actually manages to testbuild it. From chbm at gnome.org Wed Apr 13 21:59:10 2005 From: chbm at gnome.org (Carlos Morgado) Date: Wed, 13 Apr 2005 21:59:10 +0000 Subject: Maintainer for Balsa Message-ID: <1113429550l.4635l.5l@sal.chbm.net> Hi, I already went over this with Warren but it must have sliped his busy mind. I'm one of Balsa's maintainers and I'd like to step up to maintain Balsa in Fedora Extras. My RH bugzilla account for this is chbm()gnome.org. Regards -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A From mattdm at mattdm.org Wed Apr 13 22:08:46 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Apr 2005 18:08:46 -0400 Subject: Request for Review - PyRTF In-Reply-To: <1113383674.9991.5.camel@fc4t2.mpeters.local> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> Message-ID: <20050413220846.GA19657@jadzia.bu.edu> On Wed, Apr 13, 2005 at 02:14:34AM -0700, Michael Peters wrote: > My spec file - http://mpeters.us/fc_extras/PyRTF.spec > My src.rpm - http://mpeters.us/fc_extras/PyRTF-0.43-1.src.rpm Shouln't this be "python-PyRTF" as per ? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sopwith at redhat.com Wed Apr 13 22:28:53 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 13 Apr 2005 18:28:53 -0400 (EDT) Subject: CVS Import Error (was: Re: Request for Preview: INADYN) In-Reply-To: <1113421627.4759.116.camel@bobcat.mine.nu> References: <1112906227.3405.81.camel@ignacio.ignacio.lan> <20050410194742.3d1db659.bugs.michael@gmx.net> <0MKwtQ-1DL1ZX0gVc-0004uE@mrelayeu.kundenserver.de> <1113254637.5131.19.camel@ignacio.ignacio.lan> <1113384931.12065.7.camel@ignacio.ignacio.lan> <0ML25U-1DLiom3mKg-0000mG@mrelayeu.kundenserver.de> <1113420200.12065.17.camel@ignacio.ignacio.lan> <1113421627.4759.116.camel@bobcat.mine.nu> Message-ID: On Wed, 13 Apr 2005, Ville [ISO-8859-1] Skytt? wrote: > On Wed, 2005-04-13 at 15:23 -0400, Ignacio Vazquez-Abrams wrote: > > [SNIP] > > > I did set up things as specified in the "Using your Fedora CVS account" > > e-mail, so I'm at a complete loss on this one... > > I received similar errors, although less of them, when trying out stuff > so you're not alone. In particular, all uploads seem to be borked now. > (I've already sent details of the errors I received to sopwith.) Hi guys, Sorry for the problem - uploads should be fixed now, and fedora-extras-commits list is back to working. Thanks for your patience with the new account system! Best, -- Elliot From ivazquez at ivazquez.net Wed Apr 13 22:32:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 18:32:35 -0400 Subject: Request for Review - PyRTF In-Reply-To: <20050413220846.GA19657@jadzia.bu.edu> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <20050413220846.GA19657@jadzia.bu.edu> Message-ID: <1113431556.12065.31.camel@ignacio.ignacio.lan> On Wed, 2005-04-13 at 18:08 -0400, Matthew Miller wrote: > On Wed, Apr 13, 2005 at 02:14:34AM -0700, Michael Peters wrote: > > My spec file - http://mpeters.us/fc_extras/PyRTF.spec > > My src.rpm - http://mpeters.us/fc_extras/PyRTF-0.43-1.src.rpm > > Shouln't this be "python-PyRTF" as per > ? Strictly speaking, yes, but the "python-" prefix is superfluous due to the upstream name starting with "Py". -- 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 Apr 13 22:37:46 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 18:37:46 -0400 Subject: Request for sponsor: swish-e Message-ID: <1113431866.12065.36.camel@ignacio.ignacio.lan> swish-e: Simple Web Indexing System for Humans - Enhanced Swish-e is Simple Web Indexing System for Humans - Enhanced. Swish-e can quickly and easily index directories of files or remote web sites and search the generated indexes. http://fedora.ivazquez.net/files/swish-e-2.4.3-1.src.rpm There will most likely be SELinux issues with this package. I'm certainly willing to accept help in solving them if anyone offers. -- 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 mattdm at mattdm.org Wed Apr 13 22:51:38 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Apr 2005 18:51:38 -0400 Subject: Request for Review - PyRTF In-Reply-To: <1113431556.12065.31.camel@ignacio.ignacio.lan> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <20050413220846.GA19657@jadzia.bu.edu> <1113431556.12065.31.camel@ignacio.ignacio.lan> Message-ID: <20050413225138.GA21359@jadzia.bu.edu> On Wed, Apr 13, 2005 at 06:32:35PM -0400, Ignacio Vazquez-Abrams wrote: > > Shouln't this be "python-PyRTF" as per > > ? > Strictly speaking, yes, but the "python-" prefix is superfluous due to > the upstream name starting with "Py". I guess there's precedent for that in PyXML and PyQt. Personally, I think the clarity is worth a little bit of redundancy, but I guess I don't have strong feelings. Either the package guidelines should be updated to say "Unless the upstream name actually already starts with 'Py'", or else we should be consistent. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From toshio at tiki-lounge.com Wed Apr 13 23:24:25 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 13 Apr 2005 16:24:25 -0700 Subject: Review needed: notecase In-Reply-To: <20050413234515.10c408d2.bugs.michael@gmx.net>; from bugs.michael@gmx.net on Wed, Apr 13, 2005 at 11:45:15PM +0200 References: <1112789435.3405.11.camel@ignacio.ignacio.lan> <1113400345.20297.7.camel@Madison.badger.com> <20050413191641.440b5e24.bugs.michael@gmx.net> <1113424669.20297.36.camel@Madison.badger.com> <20050413234515.10c408d2.bugs.michael@gmx.net> Message-ID: <20050413162425.A7457@tiki-lounge.com> On Wed, Apr 13, 2005 at 11:45:15PM +0200, Michael Schwendt wrote: > On Wed, 13 Apr 2005 16:37:47 -0400, Toshio wrote: > > > > It's on the wiki at: http://www.fedoraproject.org/wiki/NewPackageProcess > > > > There was some discussion on packaging-list about justification of which > > this one stuck in my mind: > > https://www.redhat.com/archives/fedora-packaging/2005-March/msg00045.html > > Oh, I even participated in that thread. ;) > > Okay, okay, so it's just stylistic nitpicking and requires packagers to > change something into something else which doesn't improve the package. > I think we've yet to see a package where somebody really tries > > Patch: foo.patch > Patch: bar.patch > > %patch -b .foo > %patch -b .bar > > and actually manages to testbuild it. > And that is a very good point. Would anyone object to me removing the patch note from the wiki page? -Toshio From funkyres at gmail.com Thu Apr 14 01:38:49 2005 From: funkyres at gmail.com (Michael Peters) Date: Wed, 13 Apr 2005 18:38:49 -0700 Subject: Request for review - gourmet Message-ID: <1113442729.27910.13.camel@fc4t2.mpeters.local> This is a noarch pygtk2 application - it manages recipes (for cooking, not procmail ;) and can import/export other popular recipe formats. This is an app for LOTD in the home - my passion :) The current version has a minor bug, when you add a recipe it does not show up in the recipe index until you restart the application, it is being actively developed so I suspect that will be fixed upstream. I do patch the desktop file so that it goes into the "Accessories" menu, which may not be the best place for it - but it was goes into the "Other" menu otherwise, I'm not sure that's the best place for it either. Thoughts? Tested on FC4T2 Older version tested (and used) on FC3 - I'll test this one on FC3 this weekend. Requires the PyRTF package I have also submitted for review (it actually will work without it, but loses some functionality) http://mpeters.us/fc_extras/gourmet.spec http://mpeters.us/fc_extras/gourmet.desktop.patch http://mpeters.us/fc_extras/gourmet-0.8.3.2-1.src.rpm From bressers at redhat.com Thu Apr 14 02:23:49 2005 From: bressers at redhat.com (Josh Bressers) Date: Wed, 13 Apr 2005 22:23:49 -0400 Subject: Review: nmh Message-ID: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> It would be appreciated it someone could review the nmh package I've created for Fedora Extras. I'll submit it and maintain it if there are no complaints. http://people.redhat.com/bressers/nmh/ Description : Nmh is an e-mail system based on, and intended to be a (mostly) compatible drop-in replacement for, the MH email system. Nmh is not a single comprehensive program. Instead, it consists of a number of fairly simple single-purpose programs for sending, receiving, saving, retrieving and otherwise manipulating mail messages. You can freely intersperse nmh commands with other shell commands or write custom scripts which utilize nmh commands. If you want to use nmh as a true e-mail user agent, you also need to install exmh to provide a user interface for it -- nmh only has a command line interface. -- JB From ivazquez at ivazquez.net Thu Apr 14 02:50:32 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 13 Apr 2005 22:50:32 -0400 Subject: Review: nmh In-Reply-To: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> References: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> Message-ID: <1113447032.17325.12.camel@ignacio.ignacio.lan> On Wed, 2005-04-13 at 22:23 -0400, Josh Bressers wrote: > http://people.redhat.com/bressers/nmh/ ! Redefining built-in macros is a Bad Idea - "freeware" is not a license - Needs db4-devel in BR - Doesn't own its lib dir. - Several files should be included in %doc: ChangeLog, COPYRIGHT, README, doc/* (except Makefile* of course) - [E:]V-R on the changelog entry -- 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 funkyres at gmail.com Thu Apr 14 03:24:36 2005 From: funkyres at gmail.com (Michael Peters) Date: Wed, 13 Apr 2005 20:24:36 -0700 Subject: Request for Review - PyRTF In-Reply-To: <1113416123.12065.10.camel@ignacio.ignacio.lan> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <1113413738.17039.0.camel@fc4t2.mpeters.local> <1113416123.12065.10.camel@ignacio.ignacio.lan> Message-ID: <1113449076.337.0.camel@fc4t2.mpeters.local> On Wed, 2005-04-13 at 14:15 -0400, Ignacio Vazquez-Abrams wrote: > > You missed the BR. noarch Python packages only need distutils, not the > whole includes/libs set. And distutils comes in the base python package. > > [ignacio at ignacio ~]$ rpm -qf /usr/lib/python2.3/distutils/ > python-2.3.4-13.1.i386 fixed From rc040203 at freenet.de Thu Apr 14 03:42:30 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 Apr 2005 05:42:30 +0200 Subject: Request for Review: monotone In-Reply-To: <1113427683.4199.84.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113424138.12065.30.camel@ignacio.ignacio.lan> <1113427683.4199.84.camel@lt16586.campus.dmacc.edu> Message-ID: <1113450150.23020.177.camel@mccallum.corsepiu.local> On Wed, 2005-04-13 at 16:28 -0500, Jeffrey C. Ollie wrote: > http://www.ocjtech.us/monotone.spec The %post/%postun scripts should be referring to %{_infodir}/monotone.info.gz instead of %{_infodir}/monotone.info Ralf From skvidal at phy.duke.edu Thu Apr 14 04:11:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Apr 2005 00:11:40 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1113411792.4759.79.camel@bobcat.mine.nu> References: <1113405216.18389.53.camel@cutter> <1113411792.4759.79.camel@bobcat.mine.nu> Message-ID: <1113451900.20426.32.camel@cutter> On Wed, 2005-04-13 at 20:03 +0300, Ville Skytt? wrote: > On Wed, 2005-04-13 at 11:13 -0400, seth vidal wrote: > > > xmms-alarm (ppc) > > No build log in > http://fedoraproject.org/extras/development/build-logs/ppc/ > > Quite a few other build logs from the mass rebuild are missing too, at > least from i386 and PPC. PPC section updated at > http://fedoraproject.org/wiki/Extras_2fFC4RebuildFailures I figured out why, too. Those are the ones with unresolved build requires. the logs weren't doing what I thought pre-build. I'm working on it now. -sv From funkyres at gmail.com Thu Apr 14 05:34:14 2005 From: funkyres at gmail.com (Michael Peters) Date: Wed, 13 Apr 2005 22:34:14 -0700 Subject: Whether tis nobler to break backwards compat or upstream compat... In-Reply-To: <1113411641.23020.172.camel@mccallum.corsepiu.local> References: <1113404131.5668.5.camel@shahms.mesd.k12.or.us> <20050413151425.GA26726@nostromo.devel.redhat.com> <1113405503.5668.8.camel@shahms.mesd.k12.or.us> <1113408014.20297.15.camel@Madison.badger.com> <1113411641.23020.172.camel@mccallum.corsepiu.local> Message-ID: <1113456854.337.4.camel@fc4t2.mpeters.local> On Wed, 2005-04-13 at 19:00 +0200, Ralf Corsepius wrote: > > I know to little about php3/php4/php5 to judge if this decision is > reasonable wrt. php. When migrating from php3 to php4 and stuff broke, we had both php3 and php4 installed - with the appropriate module being used depending upon the configuration for the directory - so they are parallel installable (at least were for php3 and php4) Then the web team cleaned up the rest of the code that php4 didn't like. From ville.skytta at iki.fi Thu Apr 14 06:50:52 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Apr 2005 09:50:52 +0300 Subject: Request for Review: monotone In-Reply-To: <1113450150.23020.177.camel@mccallum.corsepiu.local> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113424138.12065.30.camel@ignacio.ignacio.lan> <1113427683.4199.84.camel@lt16586.campus.dmacc.edu> <1113450150.23020.177.camel@mccallum.corsepiu.local> Message-ID: <1113461452.4679.9.camel@bobcat.mine.nu> On Thu, 2005-04-14 at 05:42 +0200, Ralf Corsepius wrote: > On Wed, 2005-04-13 at 16:28 -0500, Jeffrey C. Ollie wrote: > > http://www.ocjtech.us/monotone.spec > > The %post/%postun scripts should be referring to > %{_infodir}/monotone.info.gz > instead of > %{_infodir}/monotone.info Not needed, install-info figures out the extension itself. But the install-info commands should have a "|| :" appended to them to support --excludedocs installs. From ville.skytta at iki.fi Thu Apr 14 07:11:05 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Apr 2005 10:11:05 +0300 Subject: "make tag" is broken Message-ID: <1113462665.4679.12.camel@bobcat.mine.nu> Oops: [scop at bobcat devel]$ make tag cvs tag -c perl-YAML-0_39-2 ERROR: Tag perl-YAML-0_39-2 is not in name-version-release format cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 [scop at bobcat devel]$ From rc040203 at freenet.de Thu Apr 14 09:50:12 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 Apr 2005 11:50:12 +0200 Subject: Request for Review: monotone In-Reply-To: <1113461452.4679.9.camel@bobcat.mine.nu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113424138.12065.30.camel@ignacio.ignacio.lan> <1113427683.4199.84.camel@lt16586.campus.dmacc.edu> <1113450150.23020.177.camel@mccallum.corsepiu.local> <1113461452.4679.9.camel@bobcat.mine.nu> Message-ID: <1113472213.6523.7.camel@mccallum.corsepiu.local> On Thu, 2005-04-14 at 09:50 +0300, Ville Skytt? wrote: > On Thu, 2005-04-14 at 05:42 +0200, Ralf Corsepius wrote: > > On Wed, 2005-04-13 at 16:28 -0500, Jeffrey C. Ollie wrote: > > > http://www.ocjtech.us/monotone.spec > > > > The %post/%postun scripts should be referring to > > %{_infodir}/monotone.info.gz > > instead of > > %{_infodir}/monotone.info > > Not needed, install-info figures out the extension itself. That's news to me. Is this behavior documented anywhere? info texinfo says: `--info-file=FILE' `-i FILE' Specify Info file to install in the directory. Equivalent to using the INFO-FILE argument. It says "FILE" not "FILE or FILE.gz" => We should not be tempted to follow undocumented program behavior. > But the > install-info commands should have a "|| :" appended to them to support > --excludedocs installs. IMO, this is irrelevant, here. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 14 06:50:43 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Apr 2005 08:50:43 +0200 Subject: Wiki RPM In-Reply-To: <1111089189.24344.13.camel@cutter> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> Message-ID: <20050414085043.3f6831c3@python2> seth vidal wrote : > > Is MoinMoin the wiki that Fedora is using (I didnt find an rpm for any > > wiki in the extras)... > > Any pointers on where to start.. I find wiki's to actually be not how > > my brain works at all so going through the Fedora wiki is giving me > > migraines at the moment. > > yes, it is moinmoin. It's not in extras right now, i just haven't had > time to submit all the packages I need to and I need to update it to > 1.3.X anyway. Any news on this? (maybe further on, I'm still catching up) I've installed MoinMoin for the first time a few weeks ago, it's really neat, and I'd definitely like to move over the user owned uncompressed files I have to a system-wide rpm-installed set of files, so I'd be more than happy to review and test any packages that would be submitted. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.20 1.26 1.31 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 14 10:44:05 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Apr 2005 12:44:05 +0200 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <20050407003855.5fc2a195.bugs.michael@gmx.net> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> <20050407003855.5fc2a195.bugs.michael@gmx.net> Message-ID: <20050414124405.61548f95@python2> Hi, Was the inserting of an empty line below every single "Release:" line done on purpose, or was it an unwanted side-effect from the script used to bump all releases? I've just gone through all the commits list emails quickly, and saw that :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 3.03 2.38 1.22 From skvidal at phy.duke.edu Thu Apr 14 12:19:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Apr 2005 08:19:39 -0400 Subject: [DONE] Re: (!) CVS devel release bump at 22:00 UTC In-Reply-To: <20050414124405.61548f95@python2> References: <20050406151625.5121f266.bugs.michael@gmx.net> <1112795085.10327.53.camel@cutter> <20050406161442.60ad3cdb.bugs.michael@gmx.net> <1112797177.10327.65.camel@cutter> <20050407003855.5fc2a195.bugs.michael@gmx.net> <20050414124405.61548f95@python2> Message-ID: <1113481179.22767.0.camel@cutter> On Thu, 2005-04-14 at 12:44 +0200, Matthias Saou wrote: > Hi, > > Was the inserting of an empty line below every single "Release:" line done > on purpose, or was it an unwanted side-effect from the script used to bump > all releases? I've just gone through all the commits list emails quickly, > and saw that :-/ > Accidental side effect. -sv From bressers at redhat.com Thu Apr 14 12:27:31 2005 From: bressers at redhat.com (Josh Bressers) Date: Thu, 14 Apr 2005 08:27:31 -0400 Subject: Review: nmh In-Reply-To: <1113447032.17325.12.camel@ignacio.ignacio.lan> References: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> <1113447032.17325.12.camel@ignacio.ignacio.lan> Message-ID: <20050414122731.GA26612@devserv.devel.redhat.com> On Wed, Apr 13, 2005 at 10:50:32PM -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-13 at 22:23 -0400, Josh Bressers wrote: > > http://people.redhat.com/bressers/nmh/ > > ! Redefining built-in macros is a Bad Idea > - "freeware" is not a license > - Needs db4-devel in BR > - Doesn't own its lib dir. > - Several files should be included in %doc: ChangeLog, COPYRIGHT, > README, doc/* (except Makefile* of course) > - [E:]V-R on the changelog entry Thanks for the feedback. These should all be taken care of (new packages at the above URL). If there are no complaints I'll import this into CVS in a few days or so. -- JB From mattdm at mattdm.org Thu Apr 14 13:06:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Apr 2005 09:06:56 -0400 Subject: new soap python packages: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <20050412215904.GA3098@jadzia.bu.edu> References: <20050412215904.GA3098@jadzia.bu.edu> Message-ID: <20050414130656.GA9633@jadzia.bu.edu> Maybe the subject of my previous message wasn't obvious enough. :) Here it is again: > So, as I mentioned a few weeks ago, I had to experiment with some SOAP > stuff recently, and discovered that the perl SOAP module gets one deep, > deep into the CPAN dependency abyss. So, I thought, Certain People are > always berating me about not using python, so why don't I check that out. > Turned out to be pretty easy. > > There's about half a dozen Python soap implementations out there, but the > two best (entirely different) come from pywebsvcs.sf.net. They are ZSI > (Zolera SOAP Infrastructure) and SOAPpy. (And SOAPpy requires fpconst.) > > > python-ZSI: > > ZSI, the Zolera SOAP Infrastructure, is a pure-Python module that > provides an implementation of SOAP messaging, as described in SOAP 1.1 > Specification (see http://www.w3.org/TR/soap). It can also be used to > build applications using SOAP Messages with Attachments (see > http://www.w3.org/TR/SOAP-attachments). ZSI is intended to make it > easier to write web services in Python. > > In particular, ZSI parses and generates SOAP messages, and converts > between native Python datatypes and SOAP syntax. Simple dispatch and > invocation methods are supported. There are no known bugs. Its only > known limitation is that it cannot handle multi-dimensional arrays. > > > python-SOAPpy: > > SOAPpy provides tools for building SOAP clients and servers. > > The goal of the SOAPpy team is to provide a full-featured SOAP library > for Python that is very simple to use and that fully supports dynamic > interaction between clients and servers. > > > python-fpconst: > > This python module implements constants and functions for working with > IEEE754 double-precision special values. It provides constants for > Not-a-Number (NaN), Positive Infinity (PosInf), and Negative Infinity > (NegInf), as well as functions to test for these values. > > > SRPMS, RPMS, and spec files at: > > > Any comments? Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 14 13:17:12 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Apr 2005 15:17:12 +0200 Subject: xmms cleanup In-Reply-To: <1112765374.10327.18.camel@cutter> References: <1112765374.10327.18.camel@cutter> Message-ID: <20050414151712.329a6ee2@python2> Hi, I'd also favor splitting off an "xmms-arts" package from the current xmms one, as well (and more importantly) as have at last "xmms-skins" built from its own source rpm. If the only thing lacking for these changes to be done is just for someone to take a few minutes to actually do them, you can count me in :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 3.25 1.87 1.16 From skvidal at phy.duke.edu Thu Apr 14 13:20:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Apr 2005 09:20:06 -0400 Subject: xmms cleanup In-Reply-To: <20050414151712.329a6ee2@python2> References: <1112765374.10327.18.camel@cutter> <20050414151712.329a6ee2@python2> Message-ID: <1113484806.22767.14.camel@cutter> On Thu, 2005-04-14 at 15:17 +0200, Matthias Saou wrote: > Hi, > > I'd also favor splitting off an "xmms-arts" package from the current xmms > one, as well (and more importantly) as have at last "xmms-skins" built > from its own source rpm. > > If the only thing lacking for these changes to be done is just for someone > to take a few minutes to actually do them, you can count me in :-) > done. do them. :) -sv From ivazquez at ivazquez.net Thu Apr 14 13:21:13 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Apr 2005 09:21:13 -0400 Subject: Review: nmh In-Reply-To: <20050414122731.GA26612@devserv.devel.redhat.com> References: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> <1113447032.17325.12.camel@ignacio.ignacio.lan> <20050414122731.GA26612@devserv.devel.redhat.com> Message-ID: <1113484873.17325.32.camel@ignacio.ignacio.lan> On Thu, 2005-04-14 at 08:27 -0400, Josh Bressers wrote: > On Wed, Apr 13, 2005 at 10:50:32PM -0400, Ignacio Vazquez-Abrams wrote: > Thanks for the feedback. These should all be taken care of (new packages > at the above URL). If there are no complaints I'll import this into CVS in > a few days or so. BuildPreReq? Did I miss that the first time? That should just be BuildRequires I think. -- 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 Apr 14 14:31:20 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 14 Apr 2005 09:31:20 -0500 Subject: Request for Review - PyRTF In-Reply-To: <20050413225138.GA21359@jadzia.bu.edu> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <20050413220846.GA19657@jadzia.bu.edu> <1113431556.12065.31.camel@ignacio.ignacio.lan> <20050413225138.GA21359@jadzia.bu.edu> Message-ID: <1113489080.3648.17.camel@localhost.localdomain> On Wed, 2005-04-13 at 18:51 -0400, Matthew Miller wrote: > On Wed, Apr 13, 2005 at 06:32:35PM -0400, Ignacio Vazquez-Abrams wrote: > > > Shouln't this be "python-PyRTF" as per > > > ? > > Strictly speaking, yes, but the "python-" prefix is superfluous due to > > the upstream name starting with "Py". > > I guess there's precedent for that in PyXML and PyQt. > > Personally, I think the clarity is worth a little bit of redundancy, but I > guess I don't have strong feelings. > > Either the package guidelines should be updated to say "Unless the upstream > name actually already starts with 'Py'", or else we should be consistent. Umm, the package guidelines say this already: http://www.fedoraproject.org/wiki/PackageNamingGuidelines#head-9a056b0f7ea52b2f6b40a4fb628372cd53ffd6bb "There is an exception to this rule. If the upstream source has "py" in its name, you can use that name for the package. So, for example, pygtk is acceptable." If the maintainer wants to call the package python-pyWhatever, as far as I'm concerned, thats fine. pyWhatever is also fine. Its up to him/her. ~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 skvidal at fedoraproject.org Thu Apr 14 14:32:20 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 14 Apr 2005 10:32:20 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1113489140.22767.37.camel@cutter> Hi Folks, Error reports only right now. galeon - missing builreqs abicheck - x86_64 failure That's it - everything else that was on the wiki page built correctly. -sv -------------- 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 mattdm at mattdm.org Thu Apr 14 15:30:28 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Apr 2005 11:30:28 -0400 Subject: Request for Review - PyRTF In-Reply-To: <1113489080.3648.17.camel@localhost.localdomain> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <20050413220846.GA19657@jadzia.bu.edu> <1113431556.12065.31.camel@ignacio.ignacio.lan> <20050413225138.GA21359@jadzia.bu.edu> <1113489080.3648.17.camel@localhost.localdomain> Message-ID: <20050414153028.GA15047@jadzia.bu.edu> On Thu, Apr 14, 2005 at 09:31:20AM -0500, Tom 'spot' Callaway wrote: > Umm, the package guidelines say this already: Oh. :) I'll shut up now then. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From adrian at lisas.de Thu Apr 14 15:49:31 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 14 Apr 2005 17:49:31 +0200 Subject: Remove Package gnome-cpufreq-applet from devel Message-ID: <20050414154931.GA5532@lisas.de> I just saw that the package gnome-cpufreq-applet was build for the development tree. gnome-cpufreq-applet, however, is included in gnome-applets which therefore should obsolete gnome-cpufreq-applet. bugzilla #154853 Can someone please remove gnome-cpufreq-applet from the development tree. Thanks. Adrian From sopwith at redhat.com Thu Apr 14 16:07:18 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 14 Apr 2005 12:07:18 -0400 (EDT) Subject: "make tag" is broken In-Reply-To: <1113462665.4679.12.camel@bobcat.mine.nu> References: <1113462665.4679.12.camel@bobcat.mine.nu> Message-ID: On Thu, 14 Apr 2005, Ville [ISO-8859-1] Skytt? wrote: > Oops: > > [scop at bobcat devel]$ make tag > cvs tag -c perl-YAML-0_39-2 > ERROR: Tag perl-YAML-0_39-2 is not in name-version-release format > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > [scop at bobcat devel]$ My bad. Fixed. -- Elliot From ville.skytta at iki.fi Thu Apr 14 17:57:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 14 Apr 2005 20:57:13 +0300 Subject: Request for Review: monotone In-Reply-To: <1113472213.6523.7.camel@mccallum.corsepiu.local> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113424138.12065.30.camel@ignacio.ignacio.lan> <1113427683.4199.84.camel@lt16586.campus.dmacc.edu> <1113450150.23020.177.camel@mccallum.corsepiu.local> <1113461452.4679.9.camel@bobcat.mine.nu> <1113472213.6523.7.camel@mccallum.corsepiu.local> Message-ID: <1113501433.4679.59.camel@bobcat.mine.nu> On Thu, 2005-04-14 at 11:50 +0200, Ralf Corsepius wrote: > On Thu, 2005-04-14 at 09:50 +0300, Ville Skytt? wrote: > > On Thu, 2005-04-14 at 05:42 +0200, Ralf Corsepius wrote: > > > > > > The %post/%postun scripts should be referring to > > > %{_infodir}/monotone.info.gz > > > instead of > > > %{_infodir}/monotone.info > > > > Not needed, install-info figures out the extension itself. > > That's news to me. Is this behavior documented anywhere? At least in the install-info source :P > => We should not be tempted to follow undocumented program behavior. Well, I'm not aware of the brp-compress magic that results in *.info magically transforming into a *.info.gz after rpmbuild's %install section being documented any better. The only difference is that the compression probably isn't news to you any more. There's no ultimately correct, documented, and failsafe solution here, but I think leaving the compress extension out instead of including it would be closer to that. Pick your poison... (BTW, FWIW, unlike the install-info behaviour, COMPRESS and COMPRESS_EXT in brp-compress smell configurable, and are actually set to something else than gzip in other distros.) > > But the > > install-info commands should have a "|| :" appended to them to support > > --excludedocs installs. > > IMO, this is irrelevant, here. IMO it's a good practice which should be applied in all install-info commands in %post and friends in all packages: in the rare cases where it might actually matter to someone installing the package, it will be there because the packager is accustomed to applying it everywhere instead of deciding on the installer's behalf whether --excludedocs installs are cool or not. I have a hunch that preventing non-zero exit code in these cases might be beneficial with %_netsharedpath /usr/share setups too, but that's just a hunch, I've no hands on experience with that. From bugs.michael at gmx.net Thu Apr 14 18:09:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Apr 2005 20:09:55 +0200 Subject: Remove Package gnome-cpufreq-applet from devel In-Reply-To: <20050414154931.GA5532@lisas.de> References: <20050414154931.GA5532@lisas.de> Message-ID: <20050414200955.0b0f8add.bugs.michael@gmx.net> On Thu, 14 Apr 2005 17:49:31 +0200, Adrian Reber wrote: > > I just saw that the package gnome-cpufreq-applet was build for the > development tree. gnome-cpufreq-applet, however, is included in > gnome-applets which therefore should obsolete gnome-cpufreq-applet. > > bugzilla #154853 > > Can someone please remove gnome-cpufreq-applet from the development > tree. Thanks. Seth can remove binary packages via FC4Status page. For CVS removal request beyond what "cvs remove" can do, see bottom of: http://fedoraproject.org/wiki/Extras/CVSSyncNeeded From Jochen at herr-schmitt.de Thu Apr 14 18:16:33 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 Apr 2005 20:16:33 +0200 Subject: Request for Review: monotone In-Reply-To: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Message-ID: On Wed, 13 Apr 2005 15:10:09 -0500, you wrote: >Continuing my quest to get more source code management tools into Fedora >Extras, here is monotone. It'll build on FC3, but fails to build on FC4 >(probably something related to gcc4). If anyone can get monotone >compiling on FC4 I'd appreciate it if you'd let me know. I have try to build your Soruce RPM on FC4 (gcc4). The build failed. The log of the tried build is uploaded on http://www.herr-schmitt.de/pub/monotone.log I assume, that all clases with virual methods need a virtual destruktor in the form virtual ~classname() {}; in the header file. Best Regards: Jochen Schmitt From jeff at ocjtech.us Thu Apr 14 20:40:24 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 14 Apr 2005 15:40:24 -0500 Subject: Request for Review: monotone In-Reply-To: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Message-ID: <1113511224.4104.3.camel@lt16586.campus.dmacc.edu> New SRPM with the %post/%postun fixes. Still won't compile on FC4, but that seems to be an upstream issue. URL: http://www.venge.net/monotone/ SRPM: http://www.ocjtech.us/monotone-0.18-0.3.src.rpm SPEC: http://www.ocjtech.us/monotone.spec Jeff Ollie -------------- 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 Thu Apr 14 21:05:52 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 14 Apr 2005 17:05:52 -0400 Subject: Review: verbiste Message-ID: Hello, all: I've committed verbiste to the Extras CVS (devel branch) -- please feel free to review it and let me know if there are any errors. I've incorporated the suggested changes, so it should be ready to go unless something else comes up. It builds and works on FC3 and FC4t2; md5sums verified with the author. Name: verbiste Summary: French conjugation system Description: Verbiste is a French conjugation system. It contains a C++ library, two programs that can be run from the command line or from another program, and a GNOME applet. This applet shows a text field in the GNOME Panel where the user can enter a conjugated verb and obtain its complete conjugation. The knowledge base is represented in XML and contains over 6800 verbs. Url: http://www3.sympatico.ca/sarrazip/dev/verbiste.html -- Konstantin Ryabitsev Zlotniks, INC From bressers at redhat.com Thu Apr 14 22:42:17 2005 From: bressers at redhat.com (Josh Bressers) Date: Thu, 14 Apr 2005 18:42:17 -0400 Subject: Review: nmh In-Reply-To: <1113484873.17325.32.camel@ignacio.ignacio.lan> References: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> <1113447032.17325.12.camel@ignacio.ignacio.lan> <20050414122731.GA26612@devserv.devel.redhat.com> <1113484873.17325.32.camel@ignacio.ignacio.lan> Message-ID: <20050414224217.GB26612@devserv.devel.redhat.com> On Thu, Apr 14, 2005 at 09:21:13AM -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-14 at 08:27 -0400, Josh Bressers wrote: > > On Wed, Apr 13, 2005 at 10:50:32PM -0400, Ignacio Vazquez-Abrams wrote: > > Thanks for the feedback. These should all be taken care of (new packages > > at the above URL). If there are no complaints I'll import this into CVS in > > a few days or so. > > BuildPreReq? Did I miss that the first time? That should just be > BuildRequires I think. I wasn't entirely sure. Much of this spec file was stolen from the nmh that was in FC1 (core). I've changed it to be a BuildRequires. OK, I've got what I hope to be the last version of this package at http://people.redhat.com/bressers/nmh/ If all is well, I assume I can claim you approved it Ignacio? Thanks. -- JB From ivazquez at ivazquez.net Fri Apr 15 00:08:21 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Apr 2005 20:08:21 -0400 Subject: Review: nmh In-Reply-To: <20050414224217.GB26612@devserv.devel.redhat.com> References: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> <1113447032.17325.12.camel@ignacio.ignacio.lan> <20050414122731.GA26612@devserv.devel.redhat.com> <1113484873.17325.32.camel@ignacio.ignacio.lan> <20050414224217.GB26612@devserv.devel.redhat.com> Message-ID: <1113523702.32387.1.camel@ignacio.ignacio.lan> On Thu, 2005-04-14 at 18:42 -0400, Josh Bressers wrote: > If all is well, I assume I can claim you approved it Ignacio? Yes, you may do so. -- 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 toshio at tiki-lounge.com Fri Apr 15 00:13:52 2005 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 14 Apr 2005 20:13:52 -0400 Subject: notecase review Message-ID: <1113524034.9132.8.camel@Madison.badger.com> Feel free to send APPROVED. * Source matches upstream * rpmlint has no valid complaints * Installs, uninstalls, and upgrades cleanly * Builds and runs on i386 and x86_64 SHA1SUMS:: 878fcf6a6e26156671c6bced9f29c015b0d1ecb4 notecase-0.8.2_src.zip fcb726bf286f5f9341d043ebd1eaa6e9fb4dd36c notecase-0.8.2-paths.patch 7fe06604be2293e53d68358450d1e491999436b2 notecase-0.8.2-strip- unix2dos.patch 898f6bc7df97777e8d5aa89850d232a51cc86c32 notecase-0.8.2-x86_64.patch 8387038cd8ad804ca9fdcbe42326195d16ca592b notecase-x86_64.patch 16317d778646c16778018b1e9331f14a61ad5903 notecase.spec -Toshio -- toshio \ 25th March, 1999: Cold rain in Georgia. Blustery blowing wind. @tiki \ Freezing fingers and tired body. Hiking on because the shelters -lounge \ are filled with other hikers. .com \__________Life is miserable -- Life is grand!_______ GA->ME 1999 -------------- 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 Apr 15 00:17:53 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Apr 2005 20:17:53 -0400 Subject: Review: nmh In-Reply-To: <1113523702.32387.1.camel@ignacio.ignacio.lan> References: <200504140223.j3E2NnKa026101@devserv.devel.redhat.com> <1113447032.17325.12.camel@ignacio.ignacio.lan> <20050414122731.GA26612@devserv.devel.redhat.com> <1113484873.17325.32.camel@ignacio.ignacio.lan> <20050414224217.GB26612@devserv.devel.redhat.com> <1113523702.32387.1.camel@ignacio.ignacio.lan> Message-ID: <1113524273.32387.2.camel@ignacio.ignacio.lan> On Thu, 2005-04-14 at 20:08 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-14 at 18:42 -0400, Josh Bressers wrote: > > If all is well, I assume I can claim you approved it Ignacio? > > Yes, you may do so. Oh wait, put a full URL on Source0 then go ahead. -- 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 dank at kegel.com Fri Apr 15 03:14:12 2005 From: dank at kegel.com (Dan Kegel) Date: Thu, 14 Apr 2005 20:14:12 -0700 Subject: Pre-pre-review request: crosstool Message-ID: <425F3184.3070805@kegel.com> I'm working on packaging gcc/glibc/binutils cross-toolchains as Fedora packages. In particular, I'd like to contribute x86 -> x86_64, x86 -> powerpc, and x86 -> sparc crosstoolchains; that would help x86 Fedora developers try cross-compiling their packages for the other supported Fedora architectures. I'll probably pick the gcc and glibc versions as Fedora normally uses. Many more combinations are possible; you can see which ones my build script tests at http://kegel.com/crosstool/crosstool-0.31/buildlogs/ but most of them are not popular enough to merit inclusion in Fedora Extras. However, I want to make it easy for anyone to build RPMs for the combinations he or she is interested in, even if prebuilt RPMs aren't available. Because there are so many possible combinations, and because I want to make it easy for people to try uncommon combinations, I'm doing things a little differently: First, each source rpm corresponds to one combination of gcc, glibc, and binutils, and generates subpackages for each desired target cpu. That cuts down on the number of source RPMs by about 10x. It's also the only sane way to handle the circular dependencies between gcc and glibc (trust me, you don't want to know). Second, I'm using a specfile template to generate the specfiles for each supported combination of gcc, glibc, and binutils. It all seems to work (knock on wood), and I'm starting to address the packaging checklist. For instance, I made sure the source rpms can be built into binary rpms by nonroot, and I've whittled down the list of rpmlint errors by a couple orders of magnitude. So, who wants to review this monster? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html From wtogami at redhat.com Fri Apr 15 03:17:00 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Apr 2005 17:17:00 -1000 Subject: Help Needed: wxGTK2 and gcc4 Message-ID: <425F322C.1090800@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154958 We need help fixing wxGTK2 to compile with gcc4. This is quite serious because it is blocking other packages from FC4. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Fri Apr 15 03:31:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Apr 2005 23:31:15 -0400 Subject: Pre-pre-review request: crosstool In-Reply-To: <425F3184.3070805@kegel.com> References: <425F3184.3070805@kegel.com> Message-ID: <20050415033115.GA13908@jadzia.bu.edu> On Thu, Apr 14, 2005 at 08:14:12PM -0700, Dan Kegel wrote: > I'm working on packaging gcc/glibc/binutils cross-toolchains > as Fedora packages. In particular, I'd like to contribute > x86 -> x86_64, x86 -> powerpc, and x86 -> sparc crosstoolchains; > that would help x86 Fedora developers try cross-compiling > their packages for the other supported Fedora architectures. > I'll probably pick the gcc and glibc versions as Fedora > normally uses. Oh, nice. Another one that'd be useful is the mingw32 cross-compiler, so I can build my SDL-based game for Windows without touching the thing. Not that you should necessarily do this right now, but I thought I'd throw this out there. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ivazquez at ivazquez.net Fri Apr 15 06:00:51 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Apr 2005 02:00:51 -0400 Subject: Pre-pre-review request: crosstool In-Reply-To: <425F3184.3070805@kegel.com> References: <425F3184.3070805@kegel.com> Message-ID: <1113544851.6806.0.camel@ignacio.ignacio.lan> On Thu, 2005-04-14 at 20:14 -0700, Dan Kegel wrote: > So, who wants to review this monster? Bring it on. -- 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 shishz at hotpop.com Fri Apr 15 06:05:04 2005 From: shishz at hotpop.com (Zing) Date: Fri, 15 Apr 2005 02:05:04 -0400 Subject: sponsor: snownews charset detect patch Message-ID: Hello folks, Could someone update snownews devel: http://home.nycap.rr.com/nagaland/rpms/snownews-1.5.6.1-4.fc4.src.rpm * Fri Apr 15 2005 Zing - 1.5.6.1-4 - runtime charset detection (debian bug #259376) thanks, zing From ivazquez at ivazquez.net Fri Apr 15 06:21:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Apr 2005 02:21:09 -0400 Subject: Help Needed: wxGTK2 and gcc4 In-Reply-To: <425F322C.1090800@redhat.com> References: <425F322C.1090800@redhat.com> Message-ID: <1113546069.6806.5.camel@ignacio.ignacio.lan> On Thu, 2005-04-14 at 17:17 -1000, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154958 > We need help fixing wxGTK2 to compile with gcc4. This is quite serious > because it is blocking other packages from FC4. Do we have a starting point, or is it pretty much "throw everything at the wall and see what sticks"? -- 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 wtogami at redhat.com Fri Apr 15 06:22:05 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Apr 2005 20:22:05 -1000 Subject: sponsor: snownews charset detect patch In-Reply-To: References: Message-ID: <425F5D8D.4060703@redhat.com> Zing wrote: > Hello folks, > > Could someone update snownews devel: > > http://home.nycap.rr.com/nagaland/rpms/snownews-1.5.6.1-4.fc4.src.rpm > > * Fri Apr 15 2005 Zing - 1.5.6.1-4 > > - runtime charset detection (debian bug #259376) > > thanks, > zing > Please provide unified diffs, it is far more difficult to review an entire spec or SRPM for changes. Thanks, Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Apr 15 06:50:50 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Apr 2005 20:50:50 -1000 Subject: sponsor: snownews charset detect patch In-Reply-To: <425F5D8D.4060703@redhat.com> References: <425F5D8D.4060703@redhat.com> Message-ID: <425F644A.8020305@redhat.com> Warren Togami wrote: > Zing wrote: > >> Hello folks, >> >> Could someone update snownews devel: >> >> http://home.nycap.rr.com/nagaland/rpms/snownews-1.5.6.1-4.fc4.src.rpm >> >> * Fri Apr 15 2005 Zing - 1.5.6.1-4 >> >> - runtime charset detection (debian bug #259376) >> >> thanks, >> zing >> > > Please provide unified diffs, it is far more difficult to review an > entire spec or SRPM for changes. > And do so in Bugzilla reports, they are nicely tracked and queryable with states and resolution when it is done. Warren From gemi at bluewin.ch Fri Apr 15 07:33:57 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 15 Apr 2005 09:33:57 +0200 Subject: Bugzilla, login and cookies Message-ID: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> Bugzilla asks me forever to login. It tells me, that cookies should be enabled. However they are, but it still does. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From funkyres at gmail.com Fri Apr 15 07:58:50 2005 From: funkyres at gmail.com (Michael Peters) Date: Fri, 15 Apr 2005 00:58:50 -0700 Subject: Bugzilla, login and cookies In-Reply-To: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> References: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> Message-ID: <1113551931.2873.37.camel@fc4t2.mpeters.local> On Fri, 2005-04-15 at 09:33 +0200, G?rard Milmeister wrote: > Bugzilla asks me forever to login. It tells me, that cookies should be > enabled. However they are, but it still does. I have experienced the same thing from time to time. Interestingly - if I log in right away at the front page, it doesn't seem to be a problem. If I do some bugzilla browsing before I log in, it may ask me to log in more that once. From svenwahl at web.de Fri Apr 15 09:21:25 2005 From: svenwahl at web.de (Sven Wahl) Date: Fri, 15 Apr 2005 11:21:25 +0200 Subject: Bugzilla, login and cookies In-Reply-To: <1113551931.2873.37.camel@fc4t2.mpeters.local> References: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> <1113551931.2873.37.camel@fc4t2.mpeters.local> Message-ID: <1113556886.4361.6.camel@lux.homenetwork> On Fri, 2005-04-15 at 00:58 -0700, Michael Peters wrote: > I have experienced the same thing from time to time. Same here ... Seems that this annoyance has been known for some time. There are already several bug reports covering that issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140689 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151237 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154460 From wtogami at redhat.com Fri Apr 15 09:47:13 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Apr 2005 23:47:13 -1000 Subject: Bugzilla, login and cookies In-Reply-To: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> References: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> Message-ID: <425F8DA1.8050205@redhat.com> G?rard Milmeister wrote: > Bugzilla asks me forever to login. It tells me, that cookies should be > enabled. However they are, but it still does. Are you behind a pool NAT or proxy that varies your outgoing IP address with different outgoing connections? Bugzilla cookies can't handle changing your public IP address. http://togami.com/~warren/ip.php Try reloading this page a few times, does the IP address ever change? (Hopefully the stuff I put in there prevents proxy servers from caching.) Warren Togami wtogami at redhat.com From nphilipp at redhat.com Fri Apr 15 10:50:59 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 15 Apr 2005 12:50:59 +0200 Subject: Review: verbiste In-Reply-To: References: Message-ID: <1113562260.14888.1.camel@gibraltar.stuttgart.redhat.com> On Thu, 2005-04-14 at 17:05 -0400, Konstantin Ryabitsev wrote: > Hello, all: > > I've committed verbiste to the Extras CVS (devel branch) -- please > feel free to review it and let me know if there are any errors. I've > incorporated the suggested changes, so it should be ready to go unless > something else comes up. > > It builds and works on FC3 and FC4t2; md5sums verified with the author. > > Name: verbiste > Summary: French conjugation system > > Description: > Verbiste is a French conjugation system. It contains a C++ library, > two programs that can be run from the command line or from another > program, and a GNOME applet. This applet shows a text field in the > GNOME Panel where the user can enter a conjugated verb and obtain its > complete conjugation. The knowledge base is represented in XML and > contains over 6800 verbs. The spec file looks good, but I'd rephrase the description a bit -- the main reason to install the package is not to have the library, but the programs using it (just my opinion). 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 funkyres at gmail.com Fri Apr 15 11:52:17 2005 From: funkyres at gmail.com (Michael Peters) Date: Fri, 15 Apr 2005 04:52:17 -0700 Subject: Starting Daemons - Wiki page? Message-ID: <1113565937.3763.1.camel@fc4t2.mpeters.local> Is there a wiki page that describes the proper procedure for staring a daemon in a %post script? From toshio at tiki-lounge.com Fri Apr 15 14:26:55 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 15 Apr 2005 07:26:55 -0700 Subject: Starting Daemons - Wiki page? In-Reply-To: <1113565937.3763.1.camel@fc4t2.mpeters.local>; from funkyres@gmail.com on Fri, Apr 15, 2005 at 04:52:17AM -0700 References: <1113565937.3763.1.camel@fc4t2.mpeters.local> Message-ID: <20050415072655.B2566@tiki-lounge.com> On Fri, Apr 15, 2005 at 04:52:17AM -0700, Michael Peters wrote: > Is there a wiki page that describes the proper procedure for staring a > daemon in a %post script? > I've just started this page:: http://www.fedoraproject.org/wiki/ScriptletSnippets Feel free to add to the Services section. If anyone else has recipes for scripts to put into an RPM %post and friends, I'd like to collect them onto this page. (At least until it becomes filled and hard to navigate.) -Toshio From gemi at bluewin.ch Fri Apr 15 15:26:53 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 15 Apr 2005 17:26:53 +0200 Subject: Bugzilla, login and cookies In-Reply-To: <425F8DA1.8050205@redhat.com> References: <1113550437.7874.1.camel@scriabin.tannenrauch.ch> <425F8DA1.8050205@redhat.com> Message-ID: <1113578813.11101.1.camel@scriabin.tannenrauch.ch> On Thu, 2005-04-14 at 23:47 -1000, Warren Togami wrote: > http://togami.com/~warren/ip.php > Try reloading this page a few times, does the IP address ever change? > (Hopefully the stuff I put in there prevents proxy servers from caching.) > The ip address stays the same, however often I reload (force reload). -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From symbiont at berlios.de Fri Apr 15 15:52:54 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 15 Apr 2005 23:52:54 +0800 Subject: Wiki RPM In-Reply-To: <20050414085043.3f6831c3@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> Message-ID: <200504152352.55085.symbiont@berlios.de> On Thursday 14 April 2005 14:50, Matthias Saou wrote: | so I'd be more | than happy to review and test any packages that would be submitted. In the interim: http://python.org/pyvault/python/2.4/noarch/html/index_testing.html And if anyone wants to use the rest as a base for something, feel free. Lately, I've not had much in terms of time. -- -jeff From dmalcolm at redhat.com Fri Apr 15 18:06:31 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 15 Apr 2005 14:06:31 -0400 Subject: Starting Daemons - Wiki page? In-Reply-To: <20050415072655.B2566@tiki-lounge.com> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> Message-ID: <1113588392.365.41.camel@cassandra.boston.redhat.com> On Fri, 2005-04-15 at 07:26 -0700, Toshio Kuratomi wrote: > On Fri, Apr 15, 2005 at 04:52:17AM -0700, Michael Peters wrote: > > Is there a wiki page that describes the proper procedure for staring a > > daemon in a %post script? > > > I've just started this page:: > http://www.fedoraproject.org/wiki/ScriptletSnippets > > Feel free to add to the Services section. Nice! Thanks. > > If anyone else has recipes for scripts to put into an RPM %post and friends, > I'd like to collect them onto this page. (At least until it becomes filled > and hard to navigate.) > > -Toshio > From jdennis at redhat.com Fri Apr 15 18:07:35 2005 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Apr 2005 14:07:35 -0400 Subject: volunteer to maintain cyrus-imapd Message-ID: <1113588455.23005.39.camel@localhost.localdomain> I will volunteer to maintain cyrus-imapd in extras. I am the current Red Hat cyrus-imapd maintainer for FC3 and RHEL4. Since I'm maintaining the package in the other releases it makes sense to do it in extras as well. I would like to give credit to Simon Matter who is the true rpm maintainer as our rpms are leveraged off Simon's and are nearly identical. I plan on importing the most current FC-4 rpm (2.2.12). This version was added to the FC-4 CVS tree shortly after cyrus-imapd was removed from core, thus it never appeared in an official FC-4 build. Version 2.2.12 has several security fixes not present in the previous 2.2.10 version. Once again, most of the credit belongs to Simon Matter. -- John Dennis From ivazquez at ivazquez.net Fri Apr 15 18:57:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Apr 2005 14:57:25 -0400 Subject: Review Needed: gnet2 Message-ID: <1113591445.6806.11.camel@ignacio.ignacio.lan> gnet2: A simple network library built upon glib -- 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 Fri Apr 15 19:23:49 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 15 Apr 2005 15:23:49 -0400 Subject: rpms/udunits/devel udunits-1.12.4-linuxfixes.patch, NONE, 1.1 udunits.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200504142159.j3ELxxwn022682@cvs-int.fedora.redhat.com> References: <200504142159.j3ELxxwn022682@cvs-int.fedora.redhat.com> Message-ID: <1113593029.16955.152.camel@ernie> On Thu, 2005-04-14 at 17:59 -0400, Tom Callaway wrote: > Author: spot > > Update of /cvs/extras/rpms/udunits/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22666/devel Hi Tom, Ah, you've cleaned up and imported udunits. Thank you!!! So I just tried the following: export CVSROOT=":ext:edhill at cvs.fedora.redhat.com:/cvs/extras" cvs co rpms/udunits cd rpms/udunits/devel/ make and got: curl: (22) The requested URL returned error: 404 make: *** [udunits-1.12.4.tar.bz2] Error 22 on two different systems. Am I overlooking something obvious? And if not, how should I try to diagnose whats wrong? Ed ps - Yes, I did update my account and get a certificate per the recent mail from Elliot. I *think* I did that correctly, but then I'm not really certain... -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 15 20:13:53 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 15 Apr 2005 22:13:53 +0200 Subject: xmms cleanup In-Reply-To: <1113484806.22767.14.camel@cutter> References: <1112765374.10327.18.camel@cutter> <20050414151712.329a6ee2@python2> <1113484806.22767.14.camel@cutter> Message-ID: <20050415221353.3f6aa708@python2> seth vidal wrote : > > I'd also favor splitting off an "xmms-arts" package from the current xmms > > one, as well (and more importantly) as have at last "xmms-skins" built > > from its own source rpm. > > > > If the only thing lacking for these changes to be done is just for someone > > to take a few minutes to actually do them, you can count me in :-) > > done. do them. :) Well, done in the devel branch : - Removed arts plugin and skins sub-package from the main xmms package - Added xmms-skins package (noarch) - Added xmms-arts package (conflicting with older xmms which included it) If people could take a look to see if I didn't mess anything up, it would be great, and I could then request a rebuild and bz components to be added (if anyone wants to volunteer for them, I wouldn't mind). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.72 1.96 1.90 From cra at WPI.EDU Fri Apr 15 21:08:01 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 15 Apr 2005 17:08:01 -0400 Subject: Sponsor Request: jigdo Message-ID: <20050415210801.GA26472@angus.ind.WPI.EDU> I'd like to import jigdo into CVS. I've built and tested this on FC3. It won't build on FC4--perhaps someone can help me with that. Jigsaw Download, or short jigdo, is a tool designed to ease the distribution of very large files over the internet, for example CD or DVD images. Its aim is to make downloading the images as easy for users as a click on a direct download link in a browser, while avoiding all the problems that server administrators have with hosting such large files. It accomplishes this by using the separate pieces of any big file (such as the files contained within a CD/DVD image) to create a special "template" file which makes reassembly of the big file very easy for users who only have the pieces. http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ Upstream: http://atterer.net/jigdo/ Licence: GPL w/OpenSSL exception Does anyone have a problem with this? From jdennis at redhat.com Fri Apr 15 21:12:43 2005 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Apr 2005 17:12:43 -0400 Subject: Request for Review: cyrus-imapd Message-ID: <1113599563.23005.55.camel@localhost.localdomain> cyrus-imap was previously in fedora core and has now been moved to extras. The most current FC4 rpm was imported into extras CVS. This is a request to review. Please note the cyrus-imapd rpm is mostly the work of Simon Matter, the rpm that was imported into extras is virtually identical to Simon's which many consider to be the "standard" cyrus- imapd rpm which is used in many distributions/systems. There have been a few minor tweaks to make it fedora friendly, but it is very close to Simon's. A few more tweaks is probably fine if deemed necessary but there is little point in diverging too much, just something to keep in mind when reviewing. To review just 'cvs co cyrus-imapd' -- John Dennis From ivazquez at ivazquez.net Fri Apr 15 21:23:12 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Apr 2005 17:23:12 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <20050415210801.GA26472@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> Message-ID: <1113600192.6806.23.camel@ignacio.ignacio.lan> On Fri, 2005-04-15 at 17:08 -0400, Chuck R. Anderson wrote: > http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ - BR should be gettext, not gettext-devel ? Is it necessary to pass --enable-debug to %configure? ? d-f-i should add the GTK category ? Icon should be put in %{_datadir}/pixmaps -- 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 funkyres at gmail.com Fri Apr 15 21:27:08 2005 From: funkyres at gmail.com (Michael Peters) Date: Fri, 15 Apr 2005 14:27:08 -0700 Subject: Sponsor Request: jigdo In-Reply-To: <20050415210801.GA26472@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> Message-ID: <1113600428.21274.8.camel@fc4t2.mpeters.local> On Fri, 2005-04-15 at 17:08 -0400, Chuck R. Anderson wrote: > I'd like to import jigdo into CVS. I've built and tested this on FC3. > It won't build on FC4--perhaps someone can help me with that. > > Jigsaw Download, or short jigdo, is a tool designed to ease the > distribution of very large files over the internet, for example CD or > DVD images. Its aim is to make downloading the images as easy for > users as a click on a direct download link in a browser, while > avoiding all the problems that server administrators have with hosting > such large files. It accomplishes this by using the separate pieces > of any big file (such as the files contained within a CD/DVD image) to > create a special "template" file which makes reassembly of the big > file very easy for users who only have the pieces. I would personally like to see it in Extras. From cra at WPI.EDU Fri Apr 15 21:39:01 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 15 Apr 2005 17:39:01 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <1113600192.6806.23.camel@ignacio.ignacio.lan> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <1113600192.6806.23.camel@ignacio.ignacio.lan> Message-ID: <20050415213901.GB26472@angus.ind.WPI.EDU> On Fri, Apr 15, 2005 at 05:23:12PM -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-04-15 at 17:08 -0400, Chuck R. Anderson wrote: > > http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ > > - BR should be gettext, not gettext-devel Can someone add me to the EditGroup so I can fix this then: http://fedoraproject.org/wiki/NewPackageProcess Thanks. > ? Is it necessary to pass --enable-debug to %configure? It was the last time I checked, otherwise an empty -debuginfo package was generated. I'll try again. > ? d-f-i should add the GTK category Done. > ? Icon should be put in %{_datadir}/pixmaps So this is out of style now? https://bugzilla.fedora.us/show_bug.cgi?id=1252#c3 From ivazquez at ivazquez.net Fri Apr 15 21:57:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Apr 2005 17:57:25 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <20050415213901.GB26472@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <1113600192.6806.23.camel@ignacio.ignacio.lan> <20050415213901.GB26472@angus.ind.WPI.EDU> Message-ID: <1113602245.6806.35.camel@ignacio.ignacio.lan> On Fri, 2005-04-15 at 17:39 -0400, Chuck R. Anderson wrote: > On Fri, Apr 15, 2005 at 05:23:12PM -0400, Ignacio Vazquez-Abrams wrote: > > On Fri, 2005-04-15 at 17:08 -0400, Chuck R. Anderson wrote: > > > http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ > > > > - BR should be gettext, not gettext-devel > > Can someone add me to the EditGroup so I can fix this then: > > http://fedoraproject.org/wiki/NewPackageProcess That's a rather strange comment. It should probably say something like "If the package has any translations, add BuildRequires: gettext and use the %find_lang macro to find them." > > ? Is it necessary to pass --enable-debug to %configure? > > It was the last time I checked, otherwise an empty -debuginfo package > was generated. I'll try again. Hmm. You may need to make a patch to remove calls to strip from the makefiles then. > > ? Icon should be put in %{_datadir}/pixmaps > > So this is out of style now? > > https://bugzilla.fedora.us/show_bug.cgi?id=1252#c3 I don't think that there's any hard rule as to where the icon should be, but I haven't seen an awful lot of apps that put their desktop icon elsewhere. Plus it makes icon themeing trickier, if you're into that sort of thing. -- 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 Fri Apr 15 22:01:27 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Apr 2005 18:01:27 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <20050415210801.GA26472@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> Message-ID: <20050415220127.GC28751@nostromo.devel.redhat.com> Chuck R. Anderson (cra at WPI.EDU) said: > It won't build on FC4--perhaps someone can help me with that. Here's the 5 second fix. Of course, the actual warnings it's spewing should probably be looked at. :) Bill -------------- next part -------------- diff -ru jigdo-0.7.1/configure jigdo-0.7.1-fixed/configure --- jigdo-0.7.1/configure 2004-06-20 16:49:15.000000000 -0400 +++ jigdo-0.7.1-fixed/configure 2005-04-15 17:56:53.000000000 -0400 @@ -6884,7 +6884,7 @@ if test "$jigdo_debug" = "yes"; then #if test "$GCC" = yes; then CFLAGS="$CFLAGS -Werror"; fi - if test "$GXX" = yes; then CXXFLAGS="$CXXFLAGS -Werror"; fi + if test "$GXX" = yes; then CXXFLAGS="$CXXFLAGS"; fi fi if test "$GXX" = "yes"; then CFLAGS="-Wall $CFLAGS -W" diff -ru jigdo-0.7.1/src/util/log.cc jigdo-0.7.1-fixed/src/util/log.cc --- jigdo-0.7.1/src/util/log.cc 2003-09-27 17:31:04.000000000 -0400 +++ jigdo-0.7.1-fixed/src/util/log.cc 2005-04-15 17:55:22.000000000 -0400 @@ -62,7 +62,7 @@ cerr << Subst::subst(format, args, arg) << endl; } -Logger::OutputFunction* Logger::output = &defaultPut; +OutputFunction* Logger::output = &defaultPut; //______________________________________________________________________ /* The value of the --debug cmd line option is either missing (empty) or a diff -ru jigdo-0.7.1/src/util/log.hh jigdo-0.7.1-fixed/src/util/log.hh --- jigdo-0.7.1/src/util/log.hh 2003-09-16 19:32:10.000000000 -0400 +++ jigdo-0.7.1-fixed/src/util/log.hh 2005-04-15 17:53:50.000000000 -0400 @@ -101,14 +101,14 @@ # endif #endif //______________________________________________________________________ + /** Logged strings are output via a OutputFunction* pointer. */ + typedef void (OutputFunction)(const string& unitName, + unsigned char unitNameLen, const char* format, int args, + const Subst arg[]); class Logger : NoCopy { public: - /** Logged strings are output via a OutputFunction* pointer. */ - typedef void (Logger::OutputFunction)(const string& unitName, - unsigned char unitNameLen, const char* format, int args, - const Subst arg[]); /** Default output function prints to stderr */ static void defaultPut(const string& unitName, unsigned char unitNameLen, const char* format, int args, const Subst arg[]); From cra at WPI.EDU Fri Apr 15 22:38:08 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 15 Apr 2005 18:38:08 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <1113602245.6806.35.camel@ignacio.ignacio.lan> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <1113600192.6806.23.camel@ignacio.ignacio.lan> <20050415213901.GB26472@angus.ind.WPI.EDU> <1113602245.6806.35.camel@ignacio.ignacio.lan> Message-ID: <20050415223808.GC26472@angus.ind.WPI.EDU> On Fri, Apr 15, 2005 at 05:57:25PM -0400, Ignacio Vazquez-Abrams wrote: > > > ? Is it necessary to pass --enable-debug to %configure? > > > > It was the last time I checked, otherwise an empty -debuginfo package > > was generated. I'll try again. > > Hmm. You may need to make a patch to remove calls to strip from the > makefiles then. This is the problem: configure: CFLAGS=`echo "$CFLAGS" | sed 's/\(^\| \)-g\( \|$\)/ /'` CXXFLAGS=`echo "$CXXFLAGS" | sed 's/\(^\| \)-g\( \|$\)/ /'` I fixed this with a patch. Thanks to Bill Nottingham for the gcc4 patch. The other issues should be addressed as well: http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ From enrico.scholz at informatik.tu-chemnitz.de Fri Apr 15 22:41:26 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 16 Apr 2005 00:41:26 +0200 Subject: Request for Review: cyrus-imapd In-Reply-To: <1113599563.23005.55.camel@localhost.localdomain> (John Dennis's message of "Fri, 15 Apr 2005 17:12:43 -0400") References: <1113599563.23005.55.camel@localhost.localdomain> Message-ID: <87d5sv7je1.fsf@kosh.bigo.ensc.de> jdennis at redhat.com (John Dennis) writes: > cyrus-imap was previously in fedora core and has now been moved to > extras. > ... > To review just 'cvs co cyrus-imapd' The location of the generated SSL certificates is a blocker for the current version. /usr/share/ssl might be shared between several hosts which would use the same certificate then. As certs are bound to DNS names, this will not work. It is a very bad idea also to have secret SSL keys on an NFS share which /usr/share might be. /usr/share is reserved for fixed data provided by the distribution but not for configuration data (local SSL certs are configuration data). Therefore, please move the SSL certs somewhere into /etc (e.g. like httpd). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tcallawa at redhat.com Sat Apr 16 00:19:42 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 15 Apr 2005 19:19:42 -0500 Subject: [Fwd: Re: rpms/udunits/devel udunits-1.12.4-linuxfixes.patch, NONE, 1.1 udunits.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2] In-Reply-To: <1113597653.16955.178.camel@ernie> References: <1113597653.16955.178.camel@ernie> Message-ID: <1113610782.11936.68.camel@localhost.localdomain> On Fri, 2005-04-15 at 16:40 -0400, Ed Hill wrote: > Hi Tom, > > Please forgive me for emailing you directly. > > I've tried to build and play with the udunits package that you just > imported (pls see below) and have failed to do a "make sources" using > trees checked out with both CVS :pserver: and :ext: methods. Both > result in 404 errors. > > In contrast, I'm having no problems with "make sources" in other > packages (eg. netcdf, xfwm4). Is there something odd about the > permissions for the "udunits-1.12.4.tar.bz2" file? Or am I just doing > something wrong? Apparently the CVS server ate my file. After reuploading, make sources works. ~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 ivazquez at ivazquez.net Sat Apr 16 00:50:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 15 Apr 2005 20:50:00 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <20050415223808.GC26472@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <1113600192.6806.23.camel@ignacio.ignacio.lan> <20050415213901.GB26472@angus.ind.WPI.EDU> <1113602245.6806.35.camel@ignacio.ignacio.lan> <20050415223808.GC26472@angus.ind.WPI.EDU> Message-ID: <1113612600.6806.40.camel@ignacio.ignacio.lan> On Fri, 2005-04-15 at 18:38 -0400, Chuck R. Anderson wrote: > The other issues should be addressed as well: > > http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ Alright, bring it on in then. -- 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 hula-kevin at iprone.com Sat Apr 16 00:33:20 2005 From: hula-kevin at iprone.com (Kevin Gray) Date: Fri, 15 Apr 2005 20:33:20 -0400 Subject: Request for Review: hula Message-ID: <200504152033.23317.hula-kevin@iprone.com> This is the second package update of hula. Information on the software can be found at www.hula-project.org. -- Kevin Gray hula [dash] kevin [at] iprone.com -------------- 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 Sat Apr 16 04:38:47 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 16 Apr 2005 00:38:47 -0400 Subject: [Fwd: Re: rpms/udunits/devel udunits-1.12.4-linuxfixes.patch, NONE, 1.1 udunits.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2] In-Reply-To: <1113610782.11936.68.camel@localhost.localdomain> References: <1113597653.16955.178.camel@ernie> <1113610782.11936.68.camel@localhost.localdomain> Message-ID: <1113626327.16955.189.camel@ernie> On Fri, 2005-04-15 at 19:19 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-04-15 at 16:40 -0400, Ed Hill wrote: > > Hi Tom, > > > > I've tried to build and play with the udunits package that you just > > imported (pls see below) and have failed to do a "make sources" using > > trees checked out with both CVS :pserver: and :ext: methods. Both > > result in 404 errors. > > Apparently the CVS server ate my file. After reuploading, make sources > works. Hi Tom, Thank you! That fixed it! 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 funkyres at gmail.com Sat Apr 16 04:39:19 2005 From: funkyres at gmail.com (Michael Peters) Date: Fri, 15 Apr 2005 21:39:19 -0700 Subject: Starting Daemons - Wiki page? In-Reply-To: <20050415072655.B2566@tiki-lounge.com> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> Message-ID: <1113626359.12190.5.camel@fc4t2.mpeters.local> On Fri, 2005-04-15 at 07:26 -0700, Toshio Kuratomi wrote: > On Fri, Apr 15, 2005 at 04:52:17AM -0700, Michael Peters wrote: > > Is there a wiki page that describes the proper procedure for staring a > > daemon in a %post script? > > > I've just started this page:: > http://www.fedoraproject.org/wiki/ScriptletSnippets > > Feel free to add to the Services section. This is why I ask - I'm writing a spec file for a package to hopefully get into livna. I started with the vendors spec file for their rpm. A feedback comment I received is that it isn't a good idea to start the service from the %post scriplet, as it can cause problems with installers. What was suggested is that I look at what the openssh-server script does. It does not start the service, it only adds it to the chkconfig system so it is configured to start at next system boot. Here is the message regarding starting of service: --- * In general, it's a bad idea to start services in the %post section. If the RPM is being installed by the Fedora installer, this can cause problems. Take a look, for instance, at the 'openssh-server' or 'xinetd' postinstall scripts: rpm -q --scripts openssh-server rpm -q --scripts xinetd --- That makes sense to me, is that what should be done with packages that contain a service? If yes, and there is a consensus, should it be part of the wiki (probably on the page ScriptletSnippets)? From bugs.michael at gmx.net Sat Apr 16 09:38:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 16 Apr 2005 11:38:46 +0200 Subject: Request for Review: hula In-Reply-To: <200504152033.23317.hula-kevin@iprone.com> References: <200504152033.23317.hula-kevin@iprone.com> Message-ID: <20050416113846.4c8d83cd.bugs.michael@gmx.net> On Fri, 15 Apr 2005 20:33:20 -0400, Kevin Gray wrote: > This is the second package update of hula. Information on the software can be > found at www.hula-project.org. > In order to build it, I've had to add the following missing build requirements: libtool (as before) openssl-devel Try to get upstream to ship a good tarball, where you don't need to run autogen.sh. > I made the changes you referenced earlier. There is one thing that I dont > completely understand due to my ignorance, and I was wondering if you had > some insight. The .so files that should be in the -devel package are required > by hula to run, so the package will always need hula and hula-devel to run. > Is this the norm for a -devel package? Thanks for the help... Well, you have moved _all_ shared libraries into the -devel packages, not just .a/.la/.so from /usr/lib, which are only needed for development. $ sudo rpm -ivh /home/qa/tmp/rpm/RPMS/hula-r178-2.i386.rpm error: Failed dependencies: libhulalogger.so.0 is needed by hula-r178-2.i386 libhulamdb.so.0 is needed by hula-r178-2.i386 libhulamemmgr.so.0 is needed by hula-r178-2.i386 libhulamsgapi.so.0 is needed by hula-r178-2.i386 libhulaxpl.so.0 is needed by hula-r178-2.i386 Generally, *.so files are symlinks pointing to versioned *.so.* libraries (note the subtle difference, *.so is not equal to *.so.*). Unless the *.so files are accessed at run-time (e.g. via dlopen), they are only needed at compile/link-time (option -lfoo in compiler command line means to link against libfoo.so). If you wanted to install multiple versions of a library at once, e.g. libfoo.so.0 and libfoo.so.1, you could not have multiple *.so symlinks with the same file name pointing to different files (should it be libfoo.so -> libfoo.so.0 or libfoo.so -> libfoo.so.1?). That's why *.so files, which are needed at compile/link-time only, usually are put into -devel packages. Programs are linked against versioned *.so.* libraries. These dependencies are caught automatically by rpmbuild (see "rpm --query --requires packagename"). Good programs, which open libraries at run-time, open versioned files too, and not non-versioned ones like "libfoo.so". Or they put run-time loaded non-versioned *.so libs into private sub-directories and not store "modules" ("plugins" or hula "snapins") in the root of %{_libdir}. Of course, where you are unsure and where parallel installation of multiple versions is not planned, you could include all *.so symlinks in the main package and don't worry. In detail: drwxr-xr-x root root 0 /usr/lib/hulamdb -rw-r--r-- root root 71460 /usr/lib/hulamdb/libmdbfile.a -rwxr-xr-x root root 68156 /usr/lib/hulamdb/libmdbfile.so This run-time loaded *.so file and its directory belong into the main package, the static archive *.a is not needed. -rw-r--r-- root root 16722 /usr/lib/libhulalogger.a lrwxrwxrwx root root 22 /usr/lib/libhulalogger.so lrwxrwxrwx root root 22 /usr/lib/libhulalogger.so.0 -rwxr-xr-x root root 19152 /usr/lib/libhulalogger.so.0.0.0 A core hula library. The *.a/*.so files can be moved into -devel package. The *.so.* files are needed in the main package. The executables are linked against them. See package dependencies quoted above. -rw-r--r-- root root 20858 /usr/lib/libhulamdb.a lrwxrwxrwx root root 19 /usr/lib/libhulamdb.so lrwxrwxrwx root root 19 /usr/lib/libhulamdb.so.0 -rwxr-xr-x root root 23604 /usr/lib/libhulamdb.so.0.0.0 Same as with libhulalogger. -rw-r--r-- root root 91808 /usr/lib/libhulamemmgr.a lrwxrwxrwx root root 22 /usr/lib/libhulamemmgr.so lrwxrwxrwx root root 22 /usr/lib/libhulamemmgr.so.0 -rwxr-xr-x root root 63192 /usr/lib/libhulamemmgr.so.0.0.0 Same as with libhulalogger. -rw-r--r-- root root 59092 /usr/lib/libhulamsgapi.a lrwxrwxrwx root root 22 /usr/lib/libhulamsgapi.so lrwxrwxrwx root root 22 /usr/lib/libhulamsgapi.so.0 -rwxr-xr-x root root 55332 /usr/lib/libhulamsgapi.so.0.0.0 Same as with libhulalogger. -rw-r--r-- root root 22218 /usr/lib/libhulaxpl.a lrwxrwxrwx root root 19 /usr/lib/libhulaxpl.so lrwxrwxrwx root root 19 /usr/lib/libhulaxpl.so.0 -rwxr-xr-x root root 19296 /usr/lib/libhulaxpl.so.0.0.0 Same as with libhulalogger. -rw-r--r-- root root 14898 /usr/lib/libwacert.a lrwxrwxrwx root root 18 /usr/lib/libwacert.so lrwxrwxrwx root root 18 /usr/lib/libwacert.so.0 -rwxr-xr-x root root 18248 /usr/lib/libwacert.so.0.0.0 -rw-r--r-- root root 35208 /usr/lib/libwanmail.a lrwxrwxrwx root root 19 /usr/lib/libwanmail.so lrwxrwxrwx root root 19 /usr/lib/libwanmail.so.0 -rwxr-xr-x root root 34584 /usr/lib/libwanmail.so.0.0.0 -rw-r--r-- root root 5818 /usr/lib/libwastdobj.a lrwxrwxrwx root root 20 /usr/lib/libwastdobj.so lrwxrwxrwx root root 20 /usr/lib/libwastdobj.so.0 -rwxr-xr-x root root 8076 /usr/lib/libwastdobj.so.0.0.0 These three above are webadmin agent modules, which belong into the main package. *.a files not needed, since *.so files are loaded at run-time, and *.so symlinks point to *.so.*, so all but *.a files are needed here. drwxr-xr-x root root 0 /usr/lib/modweb -rw-r--r-- root root 4174572 /usr/lib/modweb/aurora.ctp -rw-r--r-- root root 253682 /usr/lib/modweb/libmwcal.a -rwxr-xr-x root root 200644 /usr/lib/modweb/libmwcal.so -rw-r--r-- root root 238438 /usr/lib/modweb/libmwmail.a -rwxr-xr-x root root 204256 /usr/lib/modweb/libmwmail.so -rw-r--r-- root root 81702 /usr/lib/modweb/libmwpref.a -rwxr-xr-x root root 72540 /usr/lib/modweb/libmwpref.so -rw-r--r-- root root 57984 /usr/lib/modweb/public.ctp Same as with the libwa*. Files *.a not needed, only the *.so are needed in the main package here. %doc INSTALL : irrelevant to end-users %doc NEWS ChangeLog : empty -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1236_FC4 loadavg: 0.01 0.01 0.03 From funkyres at gmail.com Sat Apr 16 11:07:38 2005 From: funkyres at gmail.com (Michael Peters) Date: Sat, 16 Apr 2005 04:07:38 -0700 Subject: Desktop file question Message-ID: <1113649658.3342.9.camel@fc4t2.mpeters.local> Desktop file attached. It passes desktop-file-validate But I have a couple questions. In upstream - Categories=GNOME;Application;Other; I've changed that to Categories=GNOME;Application;Other;X-Red-Hat-Extra;X-Fedora; Should I drop the "X-Red-Hat-Extra" ? I don't see that mentioned in the wiki. also the Extras_2fFedoraDesktopEntryGuidelines page mentions something called the vendor prefix. What is that? I did not find it described on the freedesktop.org desktop-entry-spec page. -------------- next part -------------- A non-text attachment was scrubbed... Name: gourmet.desktop Type: application/x-desktop Size: 249 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Apr 16 11:17:53 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 16 Apr 2005 14:17:53 +0300 Subject: Desktop file question In-Reply-To: <1113649658.3342.9.camel@fc4t2.mpeters.local> References: <1113649658.3342.9.camel@fc4t2.mpeters.local> Message-ID: <1113650273.4421.32.camel@bobcat.mine.nu> On Sat, 2005-04-16 at 04:07 -0700, Michael Peters wrote: > also the Extras_2fFedoraDesktopEntryGuidelines page mentions something > called the vendor prefix. What is that? I did not find it described on > the freedesktop.org desktop-entry-spec page. See "desktop-file-install --help". Also clarified in Wiki now. From funkyres at gmail.com Sat Apr 16 12:44:07 2005 From: funkyres at gmail.com (Michael Peters) Date: Sat, 16 Apr 2005 05:44:07 -0700 Subject: Request for review - gourmet In-Reply-To: <1113442729.27910.13.camel@fc4t2.mpeters.local> References: <1113442729.27910.13.camel@fc4t2.mpeters.local> Message-ID: <485bb88405041605447dfad93a@mail.gmail.com> I fixed some things and updated http://mpeters.us/fc_extras/gourmet.spec http://mpeters.us/fc_extras/gourmet.desktop.patch http://mpeters.us/fc_extras/gourmet-0.8.3.3-1.src.rpm -- http://mpeters.us/ From skvidal at fedoraproject.org Sat Apr 16 16:46:30 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 16 Apr 2005 12:46:30 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1113669991.22733.14.camel@cutter> Build Errors: udunits - x86_64 build error A number of 'make srpm' errors happened but I reported them individually and they've been corrected. Thanks, -sv -------------- 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 fedoraproject.org Sat Apr 16 22:05:55 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 16 Apr 2005 18:05:55 -0400 Subject: Fedora Extras 3 Package Report Message-ID: <1113689155.22733.37.camel@cutter> Fedora Extras 3 Package Report: Built: R cfengine galeon gazpacho gnome-theme-clearlooks-bigpack gwenview libosip lock-keys-applet nmh perl-Config-Record perl-Module-Build perl-Module-CoreList perl-Module-Signature perl-YAML python-HTMLgen python-amara python-durus python-elementtree python-reportlab rpmlint tla zope Errors: make srpm errors: feh graveman python-cherrypy python-cherrytemplate build errors: leafpad gcl - buildrequires 'tex' -sv -------------- 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 fedoraproject.org Sun Apr 17 00:17:45 2005 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 16 Apr 2005 20:17:45 -0400 Subject: Fedora Extras Development Package Report Message-ID: <1113697065.22733.45.camel@cutter> Build Errors: QuantLib - build error on all arches - see logs Otherwise things built. -sv -------------- 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 alexl at users.sourceforge.net Sun Apr 17 00:32:09 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 16 Apr 2005 17:32:09 -0700 Subject: Fedora Extras 3 Package Report In-Reply-To: <1113689155.22733.37.camel@cutter> (seth vidal's message of "Sat, 16 Apr 2005 18:05:55 -0400") References: <1113689155.22733.37.camel@cutter> Message-ID: >>>>> "SV" == seth vidal writes: SV> Fedora Extras 3 Package Report: SV> Built: [...] SV> galeon [...] Thanks for rebuilding galeon, however it is galeon-1.3.19 and there is a more recent upstream version: galeon-1.3.20, I have filed a bugzilla report about this, just wondering who would normally update the package in CVS? https://bugzilla.redhat.com/153937 Alex From paul at all-the-johnsons.co.uk Sun Apr 17 00:32:29 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 17 Apr 2005 01:32:29 +0100 Subject: Fedora Extras Development Package Report In-Reply-To: <1113697065.22733.45.camel@cutter> References: <1113697065.22733.45.camel@cutter> Message-ID: <1113697949.5792.72.camel@localhost.localdomain> Hi, > Otherwise things built. I've put it into bugzilla, but there seems to be problems with the current version of wxGTK in fedextras with missing symbols. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155142 which has effects on other applications. Does the build process in FC-extras find the problems I've highlighted here? (Sorry if this is a dumb question) TTFN Paul -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 Sun Apr 17 00:34:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 16 Apr 2005 20:34:47 -0400 Subject: Fedora Extras 3 Package Report In-Reply-To: References: <1113689155.22733.37.camel@cutter> Message-ID: <1113698087.22733.47.camel@cutter> On Sat, 2005-04-16 at 17:32 -0700, Alex Lancaster wrote: > >>>>> "SV" == seth vidal writes: > > SV> Fedora Extras 3 Package Report: > SV> Built: > > [...] > > SV> galeon > > [...] > > Thanks for rebuilding galeon, however it is galeon-1.3.19 and there is > a more recent upstream version: galeon-1.3.20, I have filed a bugzilla > report about this, just wondering who would normally update the > package in CVS? > > https://bugzilla.redhat.com/153937 > the package owner and that's who should get the bug if you filed it against fedora extras. -sv From skvidal at phy.duke.edu Sun Apr 17 00:35:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 16 Apr 2005 20:35:46 -0400 Subject: Fedora Extras Development Package Report In-Reply-To: <1113697949.5792.72.camel@localhost.localdomain> References: <1113697065.22733.45.camel@cutter> <1113697949.5792.72.camel@localhost.localdomain> Message-ID: <1113698146.22733.49.camel@cutter> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155142 > > which has effects on other applications. > > Does the build process in FC-extras find the problems I've highlighted > here? > > (Sorry if this is a dumb question) > it's probably more like audacity needs to be rebuilt. -sv From paul at all-the-johnsons.co.uk Sun Apr 17 00:40:30 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 17 Apr 2005 01:40:30 +0100 Subject: Fedora Extras Development Package Report In-Reply-To: <1113698146.22733.49.camel@cutter> References: <1113697065.22733.45.camel@cutter> <1113697949.5792.72.camel@localhost.localdomain> <1113698146.22733.49.camel@cutter> Message-ID: <1113698430.5792.76.camel@localhost.localdomain> Hi, > it's probably more like audacity needs to be rebuilt. I've tried rebuilding audacity from the sourceforge tarball and get wx errors when compiling /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: undefined reference to `wxwxListStringNode::~wxwxListStringNode()' /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: undefined reference to `wxwxMenuItemListNode::~wxwxMenuItemListNode()' /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: undefined reference to `wxwxMenuItemListNode::~wxwxMenuItemListNode()' /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: undefined reference to `vtable for wxFileProto' /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: undefined reference to `wxwxListStringNode::~wxwxListStringNode()' They're not Audacity errors! TTFN Paul -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 funkyres at gmail.com Sun Apr 17 01:40:26 2005 From: funkyres at gmail.com (Michael Peters) Date: Sat, 16 Apr 2005 18:40:26 -0700 Subject: i18n guidelines? Message-ID: <1113702026.508.15.camel@fc4t2.mpeters.local> I did not see anything in the wiki about this. A spec file I'm working on puts all of its i18n stuff into /usr/share/gourmet/i18n That means I can't use the find_lang macro on it, find_lang doesn't look there. Looking at other packages that have i18n stuff - it looks like (from what I have installed) vim is the only other package on my system that puts any internationalization stuff into a /usr/share/package directory. Does the package need to be patched to instead put its international stuff into /usr/share/locale ? In the python - (in one file) datad=os.path.join(usr,'share','gourmet') (in another) locale.setlocale(locale.LC_ALL,'') DIR = os.path.join(datad,'i18n') gettext.bindtextdomain('gourmet',DIR) gettext.textdomain('gourmet') gettext.install('gourmet',DIR,unicode=1) so it looks like I would just need to adjust DIR to point to the /usr/share/locale instead of /usr/share/gourmet/i18n (and adjust setup.py to put it in /usr/share/locale) Would this be something I should do (as in its broken, doesn't fit guidelines), or is there no issue and would it be better to leave it the way upstream does it (as in don't fix what ain't broke)? Using find_lang of course is desirable. I apologize to everyone who doesn't use English for my ignorance on internationalization ... From funkyres at gmail.com Sun Apr 17 01:50:21 2005 From: funkyres at gmail.com (Michael Peters) Date: Sat, 16 Apr 2005 18:50:21 -0700 Subject: i18n guidelines? In-Reply-To: <1113702026.508.15.camel@fc4t2.mpeters.local> References: <1113702026.508.15.camel@fc4t2.mpeters.local> Message-ID: <485bb88405041618501c98c464@mail.gmail.com> On 4/16/05, Michael Peters wrote: > > Does the package need to be patched to instead put its international > stuff into /usr/share/locale ? Looking at FHS - http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS15 It seems to indicate that the /usr/share/locale directory is an optional part of the guidelines, but must be there if the subsystem is used, so I'm guessing I do need to patch gourmet to use it for its i18n ?? -- http://mpeters.us/ From denis at poolshark.org Sun Apr 17 02:31:01 2005 From: denis at poolshark.org (Denis Leroy) Date: Sat, 16 Apr 2005 19:31:01 -0700 Subject: Fedora Extras Development Package Report In-Reply-To: <1113698430.5792.76.camel@localhost.localdomain> References: <1113697065.22733.45.camel@cutter> <1113697949.5792.72.camel@localhost.localdomain> <1113698146.22733.49.camel@cutter> <1113698430.5792.76.camel@localhost.localdomain> Message-ID: <4261CA65.1020000@poolshark.org> This is related to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154958 Patches were submitted. They're indeed wxGTK2 issues. Paul wrote: >Hi, > > > >>it's probably more like audacity needs to be rebuilt. >> >> > >I've tried rebuilding audacity from the sourceforge tarball and get wx >errors when compiling > >/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: >undefined reference to `wxwxListStringNode::~wxwxListStringNode()' >/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: >undefined reference to `wxwxMenuItemListNode::~wxwxMenuItemListNode()' >/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: >undefined reference to `wxwxMenuItemListNode::~wxwxMenuItemListNode()' >/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: >undefined reference to `vtable for wxFileProto' >/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libwx_gtk2-2.4.so: >undefined reference to `wxwxListStringNode::~wxwxListStringNode()' > >They're not Audacity errors! > >TTFN > >Paul > > > >------------------------------------------------------------------------ > >-- >fedora-extras-list mailing list >fedora-extras-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-extras-list > > From kaboom at oobleck.net Sun Apr 17 05:26:16 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sun, 17 Apr 2005 01:26:16 -0400 (EDT) Subject: Starting Daemons - Wiki page? In-Reply-To: <1113626359.12190.5.camel@fc4t2.mpeters.local> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> <1113626359.12190.5.camel@fc4t2.mpeters.local> Message-ID: On Fri, 15 Apr 2005, Michael Peters wrote: > A feedback comment I received is that it isn't a good idea to start the > service from the %post scriplet, as it can cause problems with > installers. > > What was suggested is that I look at what the openssh-server script > does. It does not start the service, it only adds it to the chkconfig > system so it is configured to start at next system boot. Actually, I'd say doing that is a bad idea as well. Use chkconfig to add it, but have it set not to autostart in any run level. The less default-on services, the better.... Standard practice is something like in the spec: %post ... chkconfig --add service_name ... %preun ... if [ "$1" = 0 ]; then service service_name stop chkconfig --del service_name fi ... %postun ... if [ "$1" != 0 ]; then service service_name condrestart fi ... (%post adds to chkconfig, %preun conditionally stops only if running, %postun conditionally restarts only if running already) in the /etc/init.d/service_name file: # chkconfig: - startnum stopnum that way it'll register through chkconfig, but not autostart for least surprise I had thought that fedora-rpmdevtools came with a full-blown template spec that included something along those lines, but it doesn't seem to be in the newest version of that rpm.... Maybe I'm misremembering? later, chris From mfleming at enlartenment.com Sun Apr 17 11:17:05 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sun, 17 Apr 2005 21:17:05 +1000 Subject: Request for review: mlmmj Message-ID: <1113736625.11362.11.camel@defender.antaresenterprises.lan> Hi, Would anyone wish to review / sponsor the MLMMJ mailing list manager software? (http://mlmmj.mmj.dk/) . It's an ezmlm-like mailing list manager intended for use with Postfix or Exim (Possibly Sendmail too but I've not tried, being a longtime Postfix aficionado ;-)) http://www.enlartenment.com/packages/fedora/3/i386/SRPMS.mf/mlmmj-1.2.4-3.fc3.mf.src.rpm The package has worked fine for me on Core 3 so far (I'm actively using it for the small announcements list I run and is relatively simple, having no external dependencies other than glibc. At the moment I don't have a spare box for Core4test so have not compiled it in that environment. I would be interested in successes / failures however (the upstream maintainer is quite responsive) I also think it would make a nice alternative to Mailman :-) Thanks in advance. Michael Fleming. -- Michael Fleming WWW: http://www.enlartenment.com/ APT/YUM Repository for Fedora Core: http://www.enlartenment.com/packages.php "Bother" said the Borg, "We've assimilated Pooh!" From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun Apr 17 11:30:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 17 Apr 2005 13:30:25 +0200 Subject: Is cvs-import.sh broken wrt to the new upload procedure? Message-ID: <20050417133025.785a1533@python2> Hi, I've used cvs-import.sh to import xmms-skins and xmms-arts on the devel branch, but seth reported that both were missing the sources. After checking, they indeed seem to not be present, which used to not be the case after a fresh import AFAIR. But the sources and .cvsignore files are correct. So I was wondering if maybe the cvs-import.sh script needed updating for the new certificate based file upload? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.7_FC3 Load : 0.35 0.25 0.22 From toshio at tiki-lounge.com Sun Apr 17 12:56:50 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 17 Apr 2005 05:56:50 -0700 Subject: i18n guidelines? In-Reply-To: <1113702026.508.15.camel@fc4t2.mpeters.local>; from funkyres@gmail.com on Sat, Apr 16, 2005 at 06:40:26PM -0700 References: <1113702026.508.15.camel@fc4t2.mpeters.local> Message-ID: <20050417055650.A10311@tiki-lounge.com> On Sat, Apr 16, 2005 at 06:40:26PM -0700, Michael Peters wrote: > I did not see anything in the wiki about this. > > A spec file I'm working on puts all of its i18n stuff into > > /usr/share/gourmet/i18n > > That means I can't use the find_lang macro on it, find_lang doesn't look > there. > > Looking at other packages that have i18n stuff - it looks like (from > what I have installed) vim is the only other package on my system that > puts any internationalization stuff into a /usr/share/package directory. > > Does the package need to be patched to instead put its international > stuff into /usr/share/locale ? > [snip] > > Would this be something I should do (as in its broken, doesn't fit > guidelines), or is there no issue and would it be better to leave it the > way upstream does it (as in don't fix what ain't broke)? > I consider it broken as I will occasionally look in /usr/share/locale to see what packages are broken WRT language marking in spec files. FHS would probably be the definitive guide.... > Using find_lang of course is desirable. > If you choose not to move the files, you'd have to mark those files manually or I will start filing bugzillas :-). So moving files is probably easiest. If the patch is as short as you describe, upstream would probably be willing to consider it and tell you if there was some issue that casued them to put them in /usr/share/gourmet instead of /usr/share/locale. -Toshio From tcallawa at redhat.com Sun Apr 17 14:45:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 17 Apr 2005 09:45:09 -0500 Subject: Is cvs-import.sh broken wrt to the new upload procedure? In-Reply-To: <20050417133025.785a1533@python2> References: <20050417133025.785a1533@python2> Message-ID: <1113749109.11936.74.camel@localhost.localdomain> On Sun, 2005-04-17 at 13:30 +0200, Matthias Saou wrote: > Hi, > > I've used cvs-import.sh to import xmms-skins and xmms-arts on the devel > branch, but seth reported that both were missing the sources. After > checking, they indeed seem to not be present, which used to not be the > case after a fresh import AFAIR. But the sources and .cvsignore files are > correct. > > So I was wondering if maybe the cvs-import.sh script needed updating for > the new certificate based file upload? I don't think so. The CVS server was misbehaving for a while, I think its working better now. ~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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun Apr 17 16:28:28 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 17 Apr 2005 18:28:28 +0200 Subject: Request for review : p7zip Message-ID: <20050417182828.7915c45d@python2> Hi, I've come across some ".7z" (seven zip) archives before, which is why I started packaging p7zip not long ago. It seems like a good candidate for Extras as it's LGPL licensed, unless it has some kind of legal problems regarding algorithms it may be using, but I haven't found any problems there after a quick look. http://p7zip.sourceforge.net/ My current packages : http://heidelberg.freshrpms.net/rpm.html?id=1134 (yes, I know 4.16 is out, I'll be updating to it shortly) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.7_FC3 Load : 0.24 0.19 0.40 From funkyres at gmail.com Sun Apr 17 18:15:43 2005 From: funkyres at gmail.com (Michael Peters) Date: Sun, 17 Apr 2005 11:15:43 -0700 Subject: i18n guidelines? In-Reply-To: <20050417055650.A10311@tiki-lounge.com> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> Message-ID: <1113761743.19927.12.camel@fc4t2.mpeters.local> On Sun, 2005-04-17 at 05:56 -0700, Toshio Kuratomi wrote: > If the patch is as short as you describe, upstream would probably be willing > to consider it and tell you if there was some issue that casued them to put > them in /usr/share/gourmet instead of /usr/share/locale. It was that simple - I tested Spanish and Portuguese. I'll e-mail the upstream about it - last time I e-mailed him a (feature) request, he replied he didn't know if he would be able to implement it or not, and the next version he did, so he's responsive. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun Apr 17 23:16:21 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 18 Apr 2005 01:16:21 +0200 Subject: Glide3 inclusion? (dropped from Core) Message-ID: <20050418011621.37c327b7@python2> Hi, While trying to rebuild xmame on FC Development + Extras Development, I got a missing dependency on Glide3. IIRC, it was dropped from Core since nothing in Core depends on it, and it's an aging library that only Alan Cox really still cared about ;-) It hasn't been imported into Extras yet, and I seem to recall this was one package that Hans was interested in picking up... Hans, if it's still the case, I'd be really grateful. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.7_FC3 Load : 0.19 0.86 1.00 From mcgrof at gmail.com Mon Apr 18 03:31:24 2005 From: mcgrof at gmail.com (Luis R. Rodriguez) Date: Sun, 17 Apr 2005 23:31:24 -0400 Subject: Sponsor request for packages: wpa_supplicant, ion2 Message-ID: <43e72e89050417203111e1c384@mail.gmail.com> Hi, I have two packages I'd like to get into the repository: * ion2 (provides pwm as well) * wpa_supplicant If we are going to push wpa_supplicant for FC4 release I think we should also push the later version of ipw driver as the current one in FC4 test 2 release has ipw2200 v1.0.0, wpa support was added until 1.01 and became pretty stable until 1.0.3. I'm using my buld of wpa_supplicant with with ipw2200 v1.0.3 on Fedora 4 test 2 release and its working all pretty smooth. It seems I need a sponsor. Anyone interested in sponsoring this work? Regards, Luis From mcgrof at gmail.com Mon Apr 18 03:47:53 2005 From: mcgrof at gmail.com (Luis R. Rodriguez) Date: Sun, 17 Apr 2005 23:47:53 -0400 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <43e72e89050417203111e1c384@mail.gmail.com> References: <43e72e89050417203111e1c384@mail.gmail.com> Message-ID: <43e72e890504172047332228cb@mail.gmail.com> Oh, and here are the spec files: http://mcgrof.com/fedora/SPECS/ion.spec http://mcgrof.com/fedora/SPECS/wpa_supplicant.spec On 4/17/05, Luis R. Rodriguez wrote: > Hi, > > I have two packages I'd like to get into the repository: > > * ion2 (provides pwm as well) > * wpa_supplicant > > If we are going to push wpa_supplicant for FC4 release I think we > should also push the later version of ipw driver as the current one in > FC4 test 2 release has ipw2200 v1.0.0, wpa support was added until > 1.01 and became pretty stable until 1.0.3. I'm using my buld of > wpa_supplicant with with ipw2200 v1.0.3 on Fedora 4 test 2 release and > its working all pretty smooth. > > It seems I need a sponsor. Anyone interested in sponsoring this work? > > Regards, > > Luis > From davej at redhat.com Mon Apr 18 04:44:28 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 18 Apr 2005 00:44:28 -0400 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <43e72e89050417203111e1c384@mail.gmail.com> References: <43e72e89050417203111e1c384@mail.gmail.com> Message-ID: <20050418044428.GA15840@redhat.com> On Sun, Apr 17, 2005 at 11:31:24PM -0400, Luis R. Rodriguez wrote: > Hi, > > I have two packages I'd like to get into the repository: > > * ion2 (provides pwm as well) > * wpa_supplicant > > If we are going to push wpa_supplicant for FC4 release I think we > should also push the later version of ipw driver as the current one in > FC4 test 2 release has ipw2200 v1.0.0, wpa support was added until > 1.01 and became pretty stable until 1.0.3. I'm using my buld of > wpa_supplicant with with ipw2200 v1.0.3 on Fedora 4 test 2 release and > its working all pretty smooth. > > It seems I need a sponsor. Anyone interested in sponsoring this work? An update of the ipw driver(s) is on the cards before FC4 final. It's just a matter of round tuits. Dave From funkyres at gmail.com Mon Apr 18 04:45:23 2005 From: funkyres at gmail.com (Michael Peters) Date: Sun, 17 Apr 2005 21:45:23 -0700 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <43e72e890504172047332228cb@mail.gmail.com> References: <43e72e89050417203111e1c384@mail.gmail.com> <43e72e890504172047332228cb@mail.gmail.com> Message-ID: <1113799523.19927.80.camel@fc4t2.mpeters.local> On Sun, 2005-04-17 at 23:47 -0400, Luis R. Rodriguez wrote: > http://mcgrof.com/fedora/SPECS/wpa_supplicant.spec On wpa_supplicant - #CONFIG_DRIVER_HERMES=y #CONFIG_DRIVER_MADWIFI=y CONFIG_DRIVER_ATMEL=y Does it need madwifi src if you uncomment that? There's a madwifi driver in livna bugzilla awaiting approval, if possible (without damning this package to livna) it would be nice if wpa_supplicant worked with it. From mcgrof at gmail.com Mon Apr 18 05:00:03 2005 From: mcgrof at gmail.com (Luis R. Rodriguez) Date: Mon, 18 Apr 2005 01:00:03 -0400 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <20050418044428.GA15840@redhat.com> References: <43e72e89050417203111e1c384@mail.gmail.com> <20050418044428.GA15840@redhat.com> Message-ID: <43e72e89050417220052798ce1@mail.gmail.com> On 4/18/05, Dave Jones wrote: > On Sun, Apr 17, 2005 at 11:31:24PM -0400, Luis R. Rodriguez wrote: > > Hi, > > > > I have two packages I'd like to get into the repository: > > > > * ion2 (provides pwm as well) > > * wpa_supplicant > > > > If we are going to push wpa_supplicant for FC4 release I think we > > should also push the later version of ipw driver as the current one in > > FC4 test 2 release has ipw2200 v1.0.0, wpa support was added until > > 1.01 and became pretty stable until 1.0.3. I'm using my buld of > > wpa_supplicant with with ipw2200 v1.0.3 on Fedora 4 test 2 release and > > its working all pretty smooth. > > > > It seems I need a sponsor. Anyone interested in sponsoring this work? > > An update of the ipw driver(s) is on the cards before FC4 final. > It's just a matter of round tuits. Well regardless I think wpa_supplicant should be available. It won't hurt. Luis From mcgrof at gmail.com Mon Apr 18 05:05:48 2005 From: mcgrof at gmail.com (Luis R. Rodriguez) Date: Mon, 18 Apr 2005 01:05:48 -0400 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <1113799523.19927.80.camel@fc4t2.mpeters.local> References: <43e72e89050417203111e1c384@mail.gmail.com> <43e72e890504172047332228cb@mail.gmail.com> <1113799523.19927.80.camel@fc4t2.mpeters.local> Message-ID: <43e72e89050417220525b34d4a@mail.gmail.com> On 4/18/05, Michael Peters wrote: > On Sun, 2005-04-17 at 23:47 -0400, Luis R. Rodriguez wrote: > > > http://mcgrof.com/fedora/SPECS/wpa_supplicant.spec > > On wpa_supplicant - > > #CONFIG_DRIVER_HERMES=y > #CONFIG_DRIVER_MADWIFI=y > CONFIG_DRIVER_ATMEL=y > > Does it need madwifi src if you uncomment that? > There's a madwifi driver in livna bugzilla awaiting approval, if > possible (without damning this package to livna) it would be nice if > wpa_supplicant worked with it. Yes and the same holds true for the broadcom support. prism54 compile works well but its support is not yet complete. Luis From j.w.r.degoede at hhs.nl Mon Apr 18 06:04:38 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 18 Apr 2005 08:04:38 +0200 Subject: Glide3 inclusion? (dropped from Core) In-Reply-To: <20050418011621.37c327b7@python2> References: <20050418011621.37c327b7@python2> Message-ID: <42634DF6.5010700@hhs.nl> Matthias Saou wrote: > Hi, > > While trying to rebuild xmame on FC Development + Extras Development, I > got a missing dependency on Glide3. IIRC, it was dropped from Core since > nothing in Core depends on it, and it's an aging library that only Alan > Cox really still cared about ;-) > > It hasn't been imported into Extras yet, and I seem to recall this was one > package that Hans was interested in picking up... Hans, if it's still the > case, I'd be really grateful. > > Matthias > You mean this Hans (me) ? AFAIK I've never shown interest in picking it up, but yeah I'm interested I still have a Voodoo 2 in my system and occasionally use it. I'm currently not at home, but I'll take a look at whipping up an initial attempt soon. Regards, Hans From michal at harddata.com Mon Apr 18 06:43:37 2005 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 18 Apr 2005 00:43:37 -0600 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <43e72e890504172047332228cb@mail.gmail.com>; from mcgrof@gmail.com on Sun, Apr 17, 2005 at 11:47:53PM -0400 References: <43e72e89050417203111e1c384@mail.gmail.com> <43e72e890504172047332228cb@mail.gmail.com> Message-ID: <20050418004337.A25871@mail.harddata.com> On Sun, Apr 17, 2005 at 11:47:53PM -0400, Luis R. Rodriguez wrote: > Oh, and here are the spec files: > > http://mcgrof.com/fedora/SPECS/ion.spec > http://mcgrof.com/fedora/SPECS/wpa_supplicant.spec In wpa_supplicant.spec .... CONFIG_CTRL_IFACE=y .... That is fine or otherwise '%{_sbindir}/wpa_cli' is rather useless but if we have that then what about CONFIG_READLINE=y too? The later is not turned on by default in order for binaries to be distributable with a BSD license as 'realine' library is GPL. I think that a Linux version will fall into the later category anyway. What about 'CONFIG_XSUPPLICANT_IFACE'? I am not sure about that myself one way or another for a default. %doc is empty. This should read at least %doc %{name}-%{version}/README %{name}-%{version}/ChangeLog as these supply the documentation as it is right now. I would be inclined to add there also a distribution version of wpa_supplicant.conf. It is %config(noreplace) so once you edited it it is gone without unpacking the package. Comments and examples in this file are really helpful showing how this works. Some explanations how to hook up that to hotplug would be also nice. In ion.spec there is %define date %(echo `LC_ALL="C" date +"%a %b %d %Y"`) %changelog * %{date} Luis R. Rodriguez Ugh! This is "cute" but it does not give you really any timeline information when you are reading a spec file, will modify %changelog if you will recompile that later and I already run into a situation when rpmbuild spit on me that changelog entries are not in a chronological order because spec included trickery like this. IMO this is a very bad idea. Use emacs to edit a spec file and it will fill that whole line for you. rpm-spec-user-full-name and rpm-spec-user-mail-address can be customized. Besides you do not really need 'echo'. Michal From rc040203 at freenet.de Mon Apr 18 07:27:29 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 18 Apr 2005 09:27:29 +0200 Subject: Sponsor request for packages: wpa_supplicant, ion2 In-Reply-To: <43e72e890504172047332228cb@mail.gmail.com> References: <43e72e89050417203111e1c384@mail.gmail.com> <43e72e890504172047332228cb@mail.gmail.com> Message-ID: <1113809249.6523.301.camel@mccallum.corsepiu.local> On Sun, 2005-04-17 at 23:47 -0400, Luis R. Rodriguez wrote: > Oh, and here are the spec files: > > http://mcgrof.com/fedora/SPECS/ion.spec This spec needs works: 1. > ./configure --prefix=%{buildroot}%{_prefix} \ > --bindir=%{buildroot}%{_bindir} \ configure --prefix=%{buildroot} ... is bogus. You probably want %configure, or to remove the %{buildroot}'s in the call to configure. 2. > %files > %{_mandir}/man1/ .. > %{_libexecdir/ You probably want %{_mandir}/man1/* and %{_libexecdir}/* 3. I didn't try to build the package, but this also looks suspicious: > %build > %{__make} \ > HAS_SYSTEM_ASPRINTF=1 \ > OPTFLAGS="%{rpmcflags}" \ > CC=%{__cc} Ralf From devrim at gunduz.org Mon Apr 18 11:03:20 2005 From: devrim at gunduz.org (Devrim GUNDUZ) Date: Mon, 18 Apr 2005 14:03:20 +0300 (EEST) Subject: New package proposal. Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, First of all, I'm new to this list. I've been building RPMs for many projects for many years, and now I'd like to contribute some of them to Fedora Core project. The first one might be PostGIS, which provides spatial extensions to PostgreSQL. This packages needs proj, geos, and gdal, and I can also provide them. I've read the guide at: http://www.fedoraproject.org/wiki/NewPackageProcess Could you please guide me to the next step? Regards, - -- Devrim GUNDUZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCY5P6tl86P3SPfQ4RAgnvAJ4x8aR0ehT40jVmAowyN0NbkjaVHwCdGAFJ Y3mWgUwPVHgmULY/E3muypo= =D09y -----END PGP SIGNATURE----- From funkyres at gmail.com Mon Apr 18 12:27:00 2005 From: funkyres at gmail.com (Michael Peters) Date: Mon, 18 Apr 2005 05:27:00 -0700 Subject: New package proposal. In-Reply-To: References: Message-ID: <1113827220.23931.10.camel@fc4t2.mpeters.local> On Mon, 2005-04-18 at 14:03 +0300, Devrim GUNDUZ wrote: > > I've read the guide at: > > http://www.fedoraproject.org/wiki/NewPackageProcess > > Could you please guide me to the next step? You need to create an account on the wiki and add yourself to the SponsorsNeeded page : http://fedoraproject.org/wiki/Extras_2fSponsorsNeeded You should have a GPG key at the MIT public key server. Your spec files should reflect the packaging guidelines: http://fedoraproject.org/wiki/PackagingGuidelines There are some same spec files etc. in /usr/share/fedora (from the fedora-rpmdevtools package) There is an extras package called rpmlint you can use to verify your src.rpm file And finally, you can help verify that the BuildRequires of your packages are complete by following the process here: http://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires Then it's just a matter of waiting for a sponsor. While waiting (like I currently am) you can request that your spec files be reviewed - by posting to this list with a link to the spec file, and there's a good chance that mistakes will be pointed out etc. so that when you are sponsored, the package is ready for a more official review and import into their cvs tree. Hopefully I covered everything, or at least covered enough. From bugs.michael at gmx.net Mon Apr 18 13:29:49 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 18 Apr 2005 15:29:49 +0200 Subject: New package proposal. In-Reply-To: References: Message-ID: <20050418152949.69627ae0.bugs.michael@gmx.net> On Mon, 18 Apr 2005 14:03:20 +0300 (EEST), Devrim GUNDUZ wrote: > Hi, > > First of all, I'm new to this list. > > I've been building RPMs for many projects for many years, and now I'd like > to contribute some of them to Fedora Core project. > > The first one might be PostGIS, which provides spatial extensions to > PostgreSQL. This packages needs proj, geos, and gdal, and I can also > provide them. PROJ is in Fedora Extras already. GEOS (first 1.x, the 2.x was needed) and GDAL have been worked on in old fedora.us QA queue before. After lots of packaging problems, a circular dependency between GDAL and GRASS (and lack of decision on how to proceed until a solution would be found/developed) stopped development of the packages. Meanwhile, one of the solutions proposed in bugzilla.fedora.us (an interface library for GDAL+GRASS) has been developed by Debian's GIS community. For reference, the links to the old tracker: GEOS - https://bugzilla.fedora.us/show_bug.cgi?id=1394 GDAL - https://bugzilla.fedora.us/show_bug.cgi?id=1964 Packages proposed for inclusion into Fedora Extras should try to avoid (most of) the issues discussed in there. [The ticket for GDAL has been an exceptionally long one.] From mattdm at mattdm.org Mon Apr 18 14:01:54 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 18 Apr 2005 10:01:54 -0400 Subject: Request for review: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <20050412215904.GA3098@jadzia.bu.edu> Message-ID: <20050418140154.GB20034@jadzia.bu.edu> Let's try again with an actual different subject line. Could someone take a look at these? Thanks. ----- Forwarded message from Matthew Miller ----- Must... start... actually... contributing... instead... of... just... talk. So, as I mentioned a few weeks ago, I had to experiment with some SOAP stuff recently, and discovered that the perl SOAP module gets one deep, deep into the CPAN dependency abyss. So, I thought, Certain People are always berating me about not using python, so why don't I check that out. Turned out to be pretty easy. There's about half a dozen Python soap implementations out there, but the two best (entirely different) come from pywebsvcs.sf.net. They are ZSI (Zolera SOAP Infrastructure) and SOAPpy. (And SOAPpy requires fpconst.) python-ZSI: ZSI, the Zolera SOAP Infrastructure, is a pure-Python module that provides an implementation of SOAP messaging, as described in SOAP 1.1 Specification (see http://www.w3.org/TR/soap). It can also be used to build applications using SOAP Messages with Attachments (see http://www.w3.org/TR/SOAP-attachments). ZSI is intended to make it easier to write web services in Python. In particular, ZSI parses and generates SOAP messages, and converts between native Python datatypes and SOAP syntax. Simple dispatch and invocation methods are supported. There are no known bugs. Its only known limitation is that it cannot handle multi-dimensional arrays. python-SOAPpy: SOAPpy provides tools for building SOAP clients and servers. The goal of the SOAPpy team is to provide a full-featured SOAP library for Python that is very simple to use and that fully supports dynamic interaction between clients and servers. python-fpconst: This python module implements constants and functions for working with IEEE754 double-precision special values. It provides constants for Not-a-Number (NaN), Positive Infinity (PosInf), and Negative Infinity (NegInf), as well as functions to test for these values. SRPMS, RPMS, and spec files at: Any comments? Thanks! ----- End forwarded message ----- -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From hula-kevin at iprone.com Mon Apr 18 14:43:29 2005 From: hula-kevin at iprone.com (Kevin Gray) Date: Mon, 18 Apr 2005 10:43:29 -0400 Subject: upload package error Message-ID: <4263C791.2000208@iprone.com> I have a question regarding the error below about uploading the source tarballs? Is this something that is wrong with my package or with the cvs server. I tried going to the url, which gave me an error as well... Unpacking source package: hula-r186-1.src.rpm... L hula-r186.tgz U hula.spec sh: line 1: fg: no job control sh: line 1: fg: no job control Checking : hula-r186.tgz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi ... ERROR: could not check remote file status make: *** [upload] Error 255 ERROR: Uploading the source tarballs failed! Kevin Gray hula-kevin at iprone.com From jdennis at redhat.com Mon Apr 18 15:19:52 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 18 Apr 2005 11:19:52 -0400 Subject: Starting Daemons - Wiki page? In-Reply-To: References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> <1113626359.12190.5.camel@fc4t2.mpeters.local> Message-ID: <1113837592.9169.8.camel@localhost.localdomain> On Sun, 2005-04-17 at 01:26 -0400, Chris Ricker wrote: > On Fri, 15 Apr 2005, Michael Peters wrote: > > > A feedback comment I received is that it isn't a good idea to start the > > service from the %post scriplet, as it can cause problems with > > installers. > > > > What was suggested is that I look at what the openssh-server script > > does. It does not start the service, it only adds it to the chkconfig > > system so it is configured to start at next system boot. > > Actually, I'd say doing that is a bad idea as well. Use chkconfig to add > it, but have it set not to autostart in any run level. The less default-on > services, the better.... > > Standard practice is something like Yes, this is the right approach. Bill Nottingham wrote up an internal wiki page on how to handle services in spec files. Maybe we can get permission to copy the contents over to the fedora wiki. The general rule is never start a service in a spec file unless it was already running. Do make chkconfig aware of the service so a user can turn the service on easily if desired. Why not start a service? Because the mere act of installing an rpm, something many people do blindly, should not change the behavior of a the system. The choice to start and run a service is an explicit act, a conscious decision of the sys admin, not an implicit side effect of installation. -- John Dennis From ed at eh3.com Mon Apr 18 15:49:15 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 18 Apr 2005 11:49:15 -0400 Subject: package sponsor request: NCO Message-ID: <1113839355.16955.273.camel@ernie> Hi folks, I'm looking for a sponsor (and reviewers) for NCO, which is a suite of utilities for manipulating NetCDF-format files. The package got part- way through the "old" Fedora review process: https://bugzilla.fedora.us/show_bug.cgi?id=1893 and I've recently updated it to address the three outstanding issues raised by David Kaplan and Michael Schwendt which were: 1) so-names include the NCO version: The NCO developers expect the API of the shared libraries to continuously change (albeit slightly) which each new *minor* release. So they have good reason to keep the so-names as they are: https://sourceforge.net/forum/forum.php? thread_id=1268088&forum_id=9831 though that may change in future releases. 2) so-lib links are now in the devel package 3) patch added to install C headers in devel package The latest SRPM can be obtained at: http://mitgcm.org/eh3/fedora_misc/nco-3.0.0-1.src.rpm and it works-for-me on both FC3 and the latest devel. Ed ps - I do intend to add udunits as an NCO dependency since Spot recently imported it into 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 -------------- 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 shahms at shahms.com Mon Apr 18 15:59:23 2005 From: shahms at shahms.com (Shahms King) Date: Mon, 18 Apr 2005 08:59:23 -0700 Subject: Review Request: bazaar Message-ID: <4263D95B.3000606@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I checked in an initial package for the 'bazaar' implementation of the GNU Arch revision control system. The module and package name is 'bazaar', I'd appreciate it if some of you kind folks would review it. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCY9la/qs2NkWy11sRAmNZAJ4/iXGCXpfCr4jKtDakvg0PnTeDmgCgiWkc +9yJMoO3omZ087rQnj8Iwz8= =PMrN -----END PGP SIGNATURE----- From tcallawa at redhat.com Mon Apr 18 16:50:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Apr 2005 11:50:08 -0500 Subject: package sponsor request: NCO In-Reply-To: <1113839355.16955.273.camel@ernie> References: <1113839355.16955.273.camel@ernie> Message-ID: <1113843008.19436.37.camel@localhost.localdomain> On Mon, 2005-04-18 at 11:49 -0400, Ed Hill wrote: > ps - I do intend to add udunits as an NCO dependency since Spot > recently imported it into Extras. Note that right now I only have udunits in devel/ ... if you need it in FC-3, lemme know. ~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 ed at eh3.com Mon Apr 18 17:42:33 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 18 Apr 2005 13:42:33 -0400 Subject: package sponsor request: NCO In-Reply-To: <1113843008.19436.37.camel@localhost.localdomain> References: <1113839355.16955.273.camel@ernie> <1113843008.19436.37.camel@localhost.localdomain> Message-ID: <1113846153.16955.290.camel@ernie> On Mon, 2005-04-18 at 11:50 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-18 at 11:49 -0400, Ed Hill wrote: > > > ps - I do intend to add udunits as an NCO dependency since Spot > > recently imported it into Extras. > > Note that right now I only have udunits in devel/ ... if you need it in > FC-3, lemme know. Yes, please! Having udunits in FC3 Extras would be nice, and not just for NCO. 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 ivazquez at ivazquez.net Mon Apr 18 17:58:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 13:58:49 -0400 Subject: Request for Review: cyrus-imapd In-Reply-To: <1113599563.23005.55.camel@localhost.localdomain> References: <1113599563.23005.55.camel@localhost.localdomain> Message-ID: <1113847129.26306.5.camel@ignacio.ignacio.lan> On Fri, 2005-04-15 at 17:12 -0400, John Dennis wrote: > To review just 'cvs co cyrus-imapd' - Summary shouldn't end with a period - License looks like BSD to me -- 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 Apr 18 18:00:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 14:00:00 -0400 Subject: Request for Review: monotone In-Reply-To: <1113511224.4104.3.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113511224.4104.3.camel@lt16586.campus.dmacc.edu> Message-ID: <1113847200.26306.7.camel@ignacio.ignacio.lan> On Thu, 2005-04-14 at 15:40 -0500, Jeffrey C. Ollie wrote: > SPEC: http://www.ocjtech.us/monotone.spec - Summary contains %name -- 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 Apr 18 18:05:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 14:05:25 -0400 Subject: Request for review : p7zip In-Reply-To: <20050417182828.7915c45d@python2> References: <20050417182828.7915c45d@python2> Message-ID: <1113847525.26306.10.camel@ignacio.ignacio.lan> On Sun, 2005-04-17 at 18:28 +0200, Matthias Saou wrote: > My current packages : > http://heidelberg.freshrpms.net/rpm.html?id=1134 - "Midnight" is misspelled ? perl should be in BuildRequires -- 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 Apr 18 18:07:31 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 14:07:31 -0400 Subject: Review Request: bazaar In-Reply-To: <4263D95B.3000606@shahms.com> References: <4263D95B.3000606@shahms.com> Message-ID: <1113847651.26306.12.camel@ignacio.ignacio.lan> On Mon, 2005-04-18 at 08:59 -0700, Shahms King wrote: > I checked in an initial package for the 'bazaar' implementation of the > GNU Arch revision control system. The module and package name is > 'bazaar', I'd appreciate it if some of you kind folks would review it. Is the grep against build/%{name}.lang really required? -- 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 Apr 18 18:13:51 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 14:13:51 -0400 Subject: Request for review: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <20050418140154.GB20034@jadzia.bu.edu> References: <20050418140154.GB20034@jadzia.bu.edu> Message-ID: <1113848032.26306.19.camel@ignacio.ignacio.lan> On Mon, 2005-04-18 at 10:01 -0400, Matthew Miller wrote: > Let's try again with an actual different subject line. Could someone take a > look at these? Thanks. Sure. When do you take a look at OpenEXR and swish-e? ;) > python-ZSI: - noarch packages should BR python, not python-devel "# shouldn't be installing files with .py extension into bin" So then would it be better to install them into %{_datadir}/%{name} and use symlinks? > python-SOAPpy: ? "BSD-style"? Perhaps just "BSD" would be fine - noarch packages should BR python, not python-devel > python-fpconst: - noarch packages should BR python, not python-devel -- 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 shahms at shahms.com Mon Apr 18 18:19:25 2005 From: shahms at shahms.com (Shahms King) Date: Mon, 18 Apr 2005 11:19:25 -0700 Subject: Review Request: bazaar In-Reply-To: <1113847651.26306.12.camel@ignacio.ignacio.lan> References: <4263D95B.3000606@shahms.com> <1113847651.26306.12.camel@ignacio.ignacio.lan> Message-ID: <4263FA2D.3090306@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: | On Mon, 2005-04-18 at 08:59 -0700, Shahms King wrote: | |>I checked in an initial package for the 'bazaar' implementation of the |>GNU Arch revision control system. The module and package name is |>'bazaar', I'd appreciate it if some of you kind folks would review it. | | | Is the grep against build/%{name}.lang really required? No, it's not ;-P I removed it. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCY/ot/qs2NkWy11sRAid6AKCrsZmG4BhsGLJfF6sdZ3/ouJqjmgCgxm8q o+okByu5hqrChFB1g43TFW0= =Yepx -----END PGP SIGNATURE----- From tcallawa at redhat.com Mon Apr 18 18:28:46 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 18 Apr 2005 13:28:46 -0500 Subject: Request for review : p7zip In-Reply-To: <1113847525.26306.10.camel@ignacio.ignacio.lan> References: <20050417182828.7915c45d@python2> <1113847525.26306.10.camel@ignacio.ignacio.lan> Message-ID: <1113848926.19436.45.camel@localhost.localdomain> On Mon, 2005-04-18 at 14:05 -0400, Ignacio Vazquez-Abrams wrote: > On Sun, 2005-04-17 at 18:28 +0200, Matthias Saou wrote: > > My current packages : > > http://heidelberg.freshrpms.net/rpm.html?id=1134 > > - "Midnight" is misspelled > ? perl should be in BuildRequires Perl doesn't need to be in BuildRequires, because perl is one of the few packages guaranteed to be present in the buildroot. To reflect this, I've merged Michael Schwendt's excellent documentation on Requires/BuildRequires into the PackagingGuidelines: http://www.fedoraproject.org/wiki/PackagingGuidelines ~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 ivazquez at ivazquez.net Mon Apr 18 18:30:48 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 14:30:48 -0400 Subject: Request for review : p7zip In-Reply-To: <1113847525.26306.10.camel@ignacio.ignacio.lan> References: <20050417182828.7915c45d@python2> <1113847525.26306.10.camel@ignacio.ignacio.lan> Message-ID: <1113849048.26306.21.camel@ignacio.ignacio.lan> On Mon, 2005-04-18 at 14:05 -0400, Ignacio Vazquez-Abrams wrote: > ? perl should be in BuildRequires Okay, never mind this one. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 18 18:33:13 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 18 Apr 2005 20:33:13 +0200 Subject: Request for review : p7zip In-Reply-To: <1113849048.26306.21.camel@ignacio.ignacio.lan> References: <20050417182828.7915c45d@python2> <1113847525.26306.10.camel@ignacio.ignacio.lan> <1113849048.26306.21.camel@ignacio.ignacio.lan> Message-ID: <20050418203313.577cdedf@python2> Ignacio Vazquez-Abrams wrote : > On Mon, 2005-04-18 at 14:05 -0400, Ignacio Vazquez-Abrams wrote: > > ? perl should be in BuildRequires > > Okay, never mind this one. Thanks for the quick review. The typo was fixed, and I've removed unnecessary stuff from the spec too. I'll import the package tomorrow at the latest. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.73 1.36 1.49 From jeff at ocjtech.us Mon Apr 18 19:07:12 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 18 Apr 2005 14:07:12 -0500 Subject: Request for Review: monotone In-Reply-To: <1113847200.26306.7.camel@ignacio.ignacio.lan> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> <1113511224.4104.3.camel@lt16586.campus.dmacc.edu> <1113847200.26306.7.camel@ignacio.ignacio.lan> Message-ID: <1113851233.27689.6.camel@lt16586.campus.dmacc.edu> On Mon, 2005-04-18 at 14:00 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-14 at 15:40 -0500, Jeffrey C. Ollie wrote: > > SPEC: http://www.ocjtech.us/monotone.spec > > - Summary contains %name Fixed, and uploaded new version. URL: http://www.venge.net/monotone/ SRPM: http://www.ocjtech.us/monotone-0.18-0.4.src.rpm SPEC: http://www.ocjtech.us/monotone.spec 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 smooge at gmail.com Mon Apr 18 20:40:44 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 18 Apr 2005 14:40:44 -0600 Subject: Wiki RPM In-Reply-To: <200504152352.55085.symbiont@berlios.de> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> Message-ID: <80d7e409050418134033260a3c@mail.gmail.com> On 4/15/05, Jeff Pitman wrote: > On Thursday 14 April 2005 14:50, Matthias Saou wrote: > | so I'd be more > | than happy to review and test any packages that would be submitted. > > In the interim: > http://python.org/pyvault/python/2.4/noarch/html/index_testing.html > > And if anyone wants to use the rest as a base for something, feel free. > Lately, I've not had much in terms of time. Crap.. Sorry I have been running around dealing with otehr issues. I will send someone what I have gotten together from Red Hat and Seth's rpms. > > -- > -jeff > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From sopwith at redhat.com Mon Apr 18 20:54:05 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 18 Apr 2005 16:54:05 -0400 (EDT) Subject: Fedora Extras: Get involved more easily! Message-ID: If you'd like to become a Fedora Extras developer, but the process of getting CVS access seemed too slow before, please visit https://admin.fedora.redhat.com/accounts/ to use the new automated system. If you had sent in a request for an account to cvs-access at fedoraproject.org, and the account was not activated, please go through the application process again with the new system. It should be a lot quicker than before! :) Best, -- Elliot From jeff at ocjtech.us Mon Apr 18 22:40:56 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 18 Apr 2005 17:40:56 -0500 Subject: Fedora Extras: Get involved more easily! In-Reply-To: References: Message-ID: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> On Mon, 2005-04-18 at 16:54 -0400, Elliot Lee wrote: > If you'd like to become a Fedora Extras developer, but the process of > getting CVS access seemed too slow before, please visit > https://admin.fedora.redhat.com/accounts/ to use the new automated system. > > If you had sent in a request for an account to > cvs-access at fedoraproject.org, and the account was not activated, please go > through the application process again with the new system. It should be a > lot quicker than before! :) Hmmm... Having a problem with the CLA process. First of all, the system does not appear to handle GPG-signed email messages. Once I replied with a non-signed email I got this back from the system: With regards to "Re: Fedora Individual Contributor License Agreement". Your message could not be processed. Reason The signature's username did not match the e-mail address on file. Any clue as to why this isn't working for me? 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 jdennis at redhat.com Mon Apr 18 22:57:31 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 18 Apr 2005 18:57:31 -0400 Subject: Request for Review: cyrus-imapd In-Reply-To: <87d5sv7je1.fsf@kosh.bigo.ensc.de> References: <1113599563.23005.55.camel@localhost.localdomain> <87d5sv7je1.fsf@kosh.bigo.ensc.de> Message-ID: <1113865051.9169.18.camel@localhost.localdomain> On Sat, 2005-04-16 at 00:41 +0200, Enrico Scholz wrote: > jdennis at redhat.com (John Dennis) writes: > > > cyrus-imap was previously in fedora core and has now been moved to > > extras. > > ... > > To review just 'cvs co cyrus-imapd' > > The location of the generated SSL certificates is a blocker for the > current version. /usr/share/ssl might be shared between several hosts > which would use the same certificate then. As certs are bound to DNS > names, this will not work. It is a very bad idea also to have secret > SSL keys on an NFS share which /usr/share might be. /usr/share is > reserved for fixed data provided by the distribution but not for > configuration data (local SSL certs are configuration data). > > Therefore, please move the SSL certs somewhere into /etc (e.g. like > httpd). The pem file is now located in the directory /etc/cyrus-imapd. If there was an old pem file in the old location (/usr/share/ssl/certs) but not one in the new location the %post install moves it to the new location. If neither the old or new locations contain a pem file then %post creates one in the new location. Also the pem file was not listed as %ghost in the %files section, this was probably an oversight, it is now a "ghost config noreplace" file. -- John Dennis From jdennis at redhat.com Mon Apr 18 23:11:08 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 18 Apr 2005 19:11:08 -0400 Subject: Request for Review: cyrus-imapd In-Reply-To: <1113847129.26306.5.camel@ignacio.ignacio.lan> References: <1113599563.23005.55.camel@localhost.localdomain> <1113847129.26306.5.camel@ignacio.ignacio.lan> Message-ID: <1113865868.9169.32.camel@localhost.localdomain> On Mon, 2005-04-18 at 13:58 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-04-15 at 17:12 -0400, John Dennis wrote: > > To review just 'cvs co cyrus-imapd' > > - Summary shouldn't end with a period There are a number of summaries in the spec file. The spec file has to be diff'ed and merged with Simon's every time there is an update. I'm not inclined to include changes like this that will show up as a difference every time when the only thing different is the trailing period. The value of this change does not seem worthwhile IMHO. > - License looks like BSD to me Hmm... Its not exactly BSD, but it's pretty close. The spec file used to say "OSI Approved", but its not in the list at http://www.opensource.org/licenses/index.php but its very close to BSD, differing only in a request that redistributions in any form contain an acknowledgment that Carnegie Mellon University was the author. I changed the license tag to BSD. -- John Dennis From ivazquez at ivazquez.net Tue Apr 19 01:06:29 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 21:06:29 -0400 Subject: sqlite 3 Message-ID: <1113872789.13656.2.camel@ignacio.ignacio.lan> Okay, it's been 2 months, time to resurrect this. If it's in Rawhide, then does it need a "maintainer" per se, or is it enough to just import the Rawhide 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 ivazquez at ivazquez.net Tue Apr 19 01:33:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 18 Apr 2005 21:33:23 -0400 Subject: Request for sponsor: gaim-bangexec Message-ID: <1113874403.13656.5.camel@ignacio.ignacio.lan> gaim-bangexec: A command interpreter plugin for Gaim !exec is a command interpreter plugin for Gaim. If you're nostalgic for chat clients like curfloo and gyach while using Gaim, then this is the plugin for you! http://fedora.ivazquez.net/yum/3/i386/SRPMS.ivazquez/gaim-bangexec-1.1.3-0.iva.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 kaboom at oobleck.net Tue Apr 19 03:31:16 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 18 Apr 2005 23:31:16 -0400 (EDT) Subject: package for review: x3270 Message-ID: Anyone willing to review x3270? It was formerly in Core, and recently dropped.... I'd like to see it in Extras. See for a SRPM Thanks! later, chris From msmart890 at access-4-free.com Tue Apr 19 03:51:37 2005 From: msmart890 at access-4-free.com (Michael Smart) Date: Mon, 18 Apr 2005 22:51:37 -0500 Subject: Starting Daemons - Wiki page? In-Reply-To: <1113565937.3763.1.camel@fc4t2.mpeters.local> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> Message-ID: <42648049.4020705@access-4-free.com> Please remove me from this list thanks Michael Peters wrote: >Is there a wiki page that describes the proper procedure for staring a >daemon in a %post script? > >-- >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 Tue Apr 19 04:52:44 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Apr 2005 18:52:44 -1000 Subject: package for review: x3270 In-Reply-To: References: Message-ID: <42648E9C.5090801@redhat.com> Chris Ricker wrote: > Anyone willing to review x3270? It was formerly in Core, and recently > dropped.... I'd like to see it in Extras. See > > > > for a SRPM > > Thanks! > > later, > chris If it was formerly in core you can import it without review, although spec cleanups would be nice. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Apr 19 04:54:31 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 18 Apr 2005 18:54:31 -1000 Subject: sqlite 3 In-Reply-To: <1113872789.13656.2.camel@ignacio.ignacio.lan> References: <1113872789.13656.2.camel@ignacio.ignacio.lan> Message-ID: <42648F07.8030407@redhat.com> Ignacio Vazquez-Abrams wrote: > Okay, it's been 2 months, time to resurrect this. > > If it's in Rawhide, then does it need a "maintainer" per se, or is it > enough to just import the Rawhide package? > Just import it and declare yourself maintainer for FE3 in the APPROVED message. Somebody has to be responsible to make sure it is built and works. Be careful that the N-V-R is "older" than the FC4 version. Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Tue Apr 19 05:14:37 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 19 Apr 2005 01:14:37 -0400 Subject: package for review: x3270 In-Reply-To: References: Message-ID: <1113887677.13656.12.camel@ignacio.ignacio.lan> On Mon, 2005-04-18 at 23:31 -0400, Chris Ricker wrote: > Anyone willing to review x3270? It was formerly in Core, and recently > dropped.... I'd like to see it in Extras. See > > > > for a SRPM Too late, it's already been imported. -- 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 Tue Apr 19 05:26:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 19 Apr 2005 01:26:42 -0400 Subject: sqlite 3 In-Reply-To: <42648F07.8030407@redhat.com> References: <1113872789.13656.2.camel@ignacio.ignacio.lan> <42648F07.8030407@redhat.com> Message-ID: <1113888402.13656.15.camel@ignacio.ignacio.lan> On Mon, 2005-04-18 at 18:54 -1000, Warren Togami wrote: > Ignacio Vazquez-Abrams wrote: > > Okay, it's been 2 months, time to resurrect this. > > > > If it's in Rawhide, then does it need a "maintainer" per se, or is it > > enough to just import the Rawhide package? > > > > Just import it and declare yourself maintainer for FE3 in the APPROVED > message. Somebody has to be responsible to make sure it is built and > works. It built properly under FC3. Except for the TCL stuff, of course. > Be careful that the N-V-R is "older" than the FC4 version. Decimal releases it is. -- 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 mpeters at mac.com Tue Apr 19 06:43:27 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 18 Apr 2005 23:43:27 -0700 Subject: Starting Daemons - Wiki page? In-Reply-To: <1113837592.9169.8.camel@localhost.localdomain> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> <1113626359.12190.5.camel@fc4t2.mpeters.local> <1113837592.9169.8.camel@localhost.localdomain> Message-ID: <1113893007.24680.20.camel@fc4t2.mpeters.local> On Mon, 2005-04-18 at 11:19 -0400, John Dennis wrote: > > Yes, this is the right approach. Bill Nottingham wrote up an internal > wiki page on how to handle services in spec files. Maybe we can get > permission to copy the contents over to the fedora wiki. I would appreciate that. From bugs.michael at gmx.net Tue Apr 19 09:50:47 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Apr 2005 11:50:47 +0200 Subject: Request for review : p7zip In-Reply-To: <1113848926.19436.45.camel@localhost.localdomain> References: <20050417182828.7915c45d@python2> <1113847525.26306.10.camel@ignacio.ignacio.lan> <1113848926.19436.45.camel@localhost.localdomain> Message-ID: <20050419115047.02f55a4b.bugs.michael@gmx.net> On Mon, 18 Apr 2005 13:28:46 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-18 at 14:05 -0400, Ignacio Vazquez-Abrams wrote: > > On Sun, 2005-04-17 at 18:28 +0200, Matthias Saou wrote: > > > My current packages : > > > http://heidelberg.freshrpms.net/rpm.html?id=1134 > > > > - "Midnight" is misspelled > > ? perl should be in BuildRequires > > Perl doesn't need to be in BuildRequires, because perl is one of the few > packages guaranteed to be present in the buildroot. > > To reflect this, I've merged Michael Schwendt's excellent documentation > on Requires/BuildRequires into the PackagingGuidelines: > > http://www.fedoraproject.org/wiki/PackagingGuidelines It looks as if the origin of those paragraphs is the fedora.us Wiki and not anything explicitly tagged with my name only. Hence assume that those paragraphs are the result of team effort (or whoever created the first major draft). From bugs.michael at gmx.net Tue Apr 19 09:56:50 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Apr 2005 11:56:50 +0200 Subject: Sponsor Request: jigdo In-Reply-To: <20050415210801.GA26472@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> Message-ID: <20050419115650.7d48108d.bugs.michael@gmx.net> On Fri, 15 Apr 2005 17:08:01 -0400, Chuck R. Anderson wrote: > I'd like to import jigdo into CVS. I've built and tested this on FC3. > It won't build on FC4--perhaps someone can help me with that. > > Jigsaw Download, or short jigdo, is a tool designed to ease the > distribution of very large files over the internet, for example CD or > DVD images. Its aim is to make downloading the images as easy for > users as a click on a direct download link in a browser, while > avoiding all the problems that server administrators have with hosting > such large files. It accomplishes this by using the separate pieces > of any big file (such as the files contained within a CD/DVD image) to > create a special "template" file which makes reassembly of the big > file very easy for users who only have the pieces. > > http://angus.ind.wpi.edu/~cra/fedora/extras/jigdo/ > > Upstream: http://atterer.net/jigdo/ > Licence: GPL w/OpenSSL exception > > Does anyone have a problem with this? No. But does it still contain so many Debian specific files and defaults? E.g. Debian mirror lists as opposed to Fedora mirror lists? I don't find that useful. If you want to lobby for jigdo distribution of Fedora ISOs, the package should at least offer some experimental Fedora-specific config defaults. From fedora at camperquake.de Tue Apr 19 12:56:08 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 19 Apr 2005 14:56:08 +0200 Subject: Request for Review: bmp-flac Message-ID: <20050419145608.6ad15254@nausicaa.camperquake.de> Hi. I have a quite simple initial version of a bmp-flac package ready for inclusion. Package and specfile at http://ryoko.camperquake.de/fedora/bmp-flac/ -- "Would you mind not shooting at the thermonuclear weapons?" -- John Travolta in "Broken Arrow" From bugs.michael at gmx.net Tue Apr 19 13:17:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Apr 2005 15:17:30 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419145608.6ad15254@nausicaa.camperquake.de> References: <20050419145608.6ad15254@nausicaa.camperquake.de> Message-ID: <20050419151730.35257143.bugs.michael@gmx.net> On Tue, 19 Apr 2005 14:56:08 +0200, Ralf Ertzinger wrote: > Hi. > > I have a quite simple initial version of a bmp-flac package ready > for inclusion. > > Package and specfile at http://ryoko.camperquake.de/fedora/bmp-flac/ * There should be no need to hardcode the BMP input plugin path in the Makefile and the spec. Use this instead (and a similar thing in the Makefile): %define plugindir %(pkg-config bmp --variable=input_plugin_dir) and %{plugindir}/libflac.so in the %files section. That also avoids multilib problems. * $RPM_OPT_FLAGS are not accepted. You need to pass CFLAGS= to "make" manually. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 13:17:26 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 15:17:26 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419145608.6ad15254@nausicaa.camperquake.de> References: <20050419145608.6ad15254@nausicaa.camperquake.de> Message-ID: <20050419151726.4dbd642d@python2> Ralf Ertzinger wrote : > I have a quite simple initial version of a bmp-flac package ready > for inclusion. > > Package and specfile at http://ryoko.camperquake.de/fedora/bmp-flac/ You've got my positive review. Just a question : Did you write the original source too? The Source URL points to an empty directory, but looking around it, the tarball can be found but it's the same host as above... just wondering. Last, I'd change the summary to : "FLAC playback plugin for the Beep Media Player" And the description to something like : "This package contains a FLAC (Free Lossless Audio Codec) playback plugin for BMP (Beep Media Player)." But that's more a matter of taste :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.73 1.16 1.02 From kaboom at oobleck.net Tue Apr 19 13:22:08 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 19 Apr 2005 09:22:08 -0400 (EDT) Subject: package for review: x3270 In-Reply-To: <1113887677.13656.12.camel@ignacio.ignacio.lan> References: <1113887677.13656.12.camel@ignacio.ignacio.lan> Message-ID: On Tue, 19 Apr 2005, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-04-18 at 23:31 -0400, Chris Ricker wrote: > > Anyone willing to review x3270? It was formerly in Core, and recently > > dropped.... I'd like to see it in Extras. See > > > > > > > > for a SRPM > > Too late, it's already been imported. Yep, scratch that -- looks like Karsten did it between the 1st and 2nd times I requested a review later, chris From tcallawa at redhat.com Tue Apr 19 13:37:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Apr 2005 08:37:54 -0500 Subject: Request for review : p7zip In-Reply-To: <20050419115047.02f55a4b.bugs.michael@gmx.net> References: <20050417182828.7915c45d@python2> <1113847525.26306.10.camel@ignacio.ignacio.lan> <1113848926.19436.45.camel@localhost.localdomain> <20050419115047.02f55a4b.bugs.michael@gmx.net> Message-ID: <1113917874.19436.61.camel@swoop> On Tue, 2005-04-19 at 11:50 +0200, Michael Schwendt wrote: > On Mon, 18 Apr 2005 13:28:46 -0500, Tom 'spot' Callaway wrote: > > > On Mon, 2005-04-18 at 14:05 -0400, Ignacio Vazquez-Abrams wrote: > > > On Sun, 2005-04-17 at 18:28 +0200, Matthias Saou wrote: > > > > My current packages : > > > > http://heidelberg.freshrpms.net/rpm.html?id=1134 > > > > > > - "Midnight" is misspelled > > > ? perl should be in BuildRequires > > > > Perl doesn't need to be in BuildRequires, because perl is one of the few > > packages guaranteed to be present in the buildroot. > > > > To reflect this, I've merged Michael Schwendt's excellent documentation > > on Requires/BuildRequires into the PackagingGuidelines: > > > > http://www.fedoraproject.org/wiki/PackagingGuidelines > > It looks as if the origin of those paragraphs is the fedora.us Wiki and > not anything explicitly tagged with my name only. Hence assume that those > paragraphs are the result of team effort (or whoever created the first > major draft). Fair enough. Thanks are redirected to the Wiki! ;) ~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 notting at redhat.com Tue Apr 19 13:37:51 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Apr 2005 09:37:51 -0400 Subject: Starting Daemons - Wiki page? In-Reply-To: <1113893007.24680.20.camel@fc4t2.mpeters.local> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> <1113626359.12190.5.camel@fc4t2.mpeters.local> <1113837592.9169.8.camel@localhost.localdomain> <1113893007.24680.20.camel@fc4t2.mpeters.local> Message-ID: <20050419133750.GA21833@nostromo.devel.redhat.com> Michael A. Peters (mpeters at mac.com) said: > > Yes, this is the right approach. Bill Nottingham wrote up an internal > > wiki page on how to handle services in spec files. Maybe we can get > > permission to copy the contents over to the fedora wiki. > > I would appreciate that. Feel free to copy whatever. :) Bill From devrim at gunduz.org Tue Apr 19 13:45:00 2005 From: devrim at gunduz.org (Devrim GUNDUZ) Date: Tue, 19 Apr 2005 16:45:00 +0300 (EEST) Subject: New package proposal. In-Reply-To: <20050418152949.69627ae0.bugs.michael@gmx.net> References: <20050418152949.69627ae0.bugs.michael@gmx.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Mon, 18 Apr 2005, Michael Schwendt wrote: >> The first one might be PostGIS, which provides spatial extensions to >> PostgreSQL. This packages needs proj, geos, and gdal, and I can also >> provide them. > > PROJ is in Fedora Extras already. GEOS (first 1.x, the 2.x was needed) and > GDAL have been worked on in old fedora.us QA queue before. After lots of > packaging problems, a circular dependency between GDAL and GRASS (and lack > of decision on how to proceed until a solution would be found/developed) > stopped development of the packages. Meanwhile, one of the solutions > proposed in bugzilla.fedora.us (an interface library for GDAL+GRASS) > has been developed by Debian's GIS community. > > For reference, the links to the old tracker: > GEOS - https://bugzilla.fedora.us/show_bug.cgi?id=1394 > GDAL - https://bugzilla.fedora.us/show_bug.cgi?id=1964 > > Packages proposed for inclusion into Fedora Extras should try to avoid > (most of) the issues discussed in there. [The ticket for GDAL has been > an exceptionally long one.] Ok, will work on those bugs... Regards, - -- Devrim GUNDUZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCZQthtl86P3SPfQ4RAliTAKDVONmrJFQAqCwDkoLZbRB3aAaroACg7JWw PqfxnvN/EQc9tyWXiH2WfAE= =obax -----END PGP SIGNATURE----- From shahms at shahms.com Tue Apr 19 14:22:06 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 19 Apr 2005 07:22:06 -0700 Subject: Review Request: bazaar In-Reply-To: <1113847651.26306.12.camel@ignacio.ignacio.lan> References: <4263D95B.3000606@shahms.com> <1113847651.26306.12.camel@ignacio.ignacio.lan> Message-ID: <4265140E.4010003@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: | On Mon, 2005-04-18 at 08:59 -0700, Shahms King wrote: | |>I checked in an initial package for the 'bazaar' implementation of the |>GNU Arch revision control system. The module and package name is |>'bazaar', I'd appreciate it if some of you kind folks would review it. | | | Is the grep against build/%{name}.lang really required? So, would you call this reviewed? Can I send an APPROVED message to commits, or would you like to? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCZRQO/qs2NkWy11sRAn8jAJ95FIoH3QBwcbaJ5gN6kUntotH0hwCgw7tB ThpqnBHQxy0NfY+8D3eubNg= =I8vR -----END PGP SIGNATURE----- From fedora at camperquake.de Tue Apr 19 14:27:36 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 19 Apr 2005 16:27:36 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419151726.4dbd642d@python2> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151726.4dbd642d@python2> Message-ID: <20050419142736.GA25583@ryoko.camperquake.de> On Tue, Apr 19, 2005 at 03:17:26PM +0200, Matthias Saou wrote: > You've got my positive review. Just a question : Did you write the > original source too? The Source URL points to an empty directory, but > looking around it, the tarball can be found but it's the same host as > above... just wondering. I took a modified version of the flac source tree where someone (I just have a mail address and a homepage) hacked upon the XMMS-plugin to make it work with BMP. I took that package and extracted and modified the code a bit to make it compile standalone. I did not manage to write a bit about this today, there will be a page about this on skytale.net. > But that's more a matter of taste :-) I do not feel a special affection to my wording, so I'll change that. From fedora at camperquake.de Tue Apr 19 14:29:17 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 19 Apr 2005 16:29:17 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419151730.35257143.bugs.michael@gmx.net> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> Message-ID: <20050419142917.GB25583@ryoko.camperquake.de> On Tue, Apr 19, 2005 at 03:17:30PM +0200, Michael Schwendt wrote: > * There should be no need to hardcode the BMP input plugin path in > the Makefile and the spec. Use this instead (and a similar thing in the > Makefile): > > %define plugindir %(pkg-config bmp --variable=input_plugin_dir) Ah, so there it is. Is there a way to show all variables that a given .pc file defines? > * $RPM_OPT_FLAGS are not accepted. You need to pass CFLAGS= to "make" > manually. Right, missed that one. From tcallawa at redhat.com Tue Apr 19 14:34:29 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Apr 2005 09:34:29 -0500 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK Message-ID: <1113921269.19436.74.camel@swoop> All packages described can be found here: http://www.auroralinux.org/people/spot/R/ Second chunk of R related packages for review, this time, I've got lapack's cousins, blacs, and scalapack, along with the first of many R modules, RScaLAPACK. The R modules are so similar that the spec template is virtually identical for each module. ==== blacs: URL: http://www.netlib.org/blacs SRPM: http://www.auroralinux.org/people/spot/R/blacs-1.1-3.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/blacs.spec The BLACS (Basic Linear Algebra Communication Subprograms) project is an ongoing investigation whose purpose is to create a linear algebra oriented message passing interface that may be implemented efficiently and uniformly across a large range of distributed memory platforms. The length of time required to implement efficient distributed memory algorithms makes it impractical to rewrite programs for every new parallel machine. The BLACS exist in order to make linear algebra applications both easier to program and more portable. scalapack: URL: http://www.netlib.org/scalapack/scalapack_home.html SRPM: http://www.auroralinux.org/people/spot/R/scalapack-1.7-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/scalapack.spec The ScaLAPACK (or Scalable LAPACK) library includes a subset of LAPACK routines redesigned for distributed memory MIMD parallel computers. It is currently written in a Single-Program-Multiple-Data style using explicit message passing for interprocessor communication. It assumes matrices are laid out in a two-dimensional block cyclic decomposition. ScaLAPACK is designed for heterogeneous computing and is portable on any computer that supports MPI or PVM. Like LAPACK, the ScaLAPACK routines are based on block-partitioned algorithms in order to minimize the frequency of data movement between different levels of the memory hierarchy. (For such machines, the memory hierarchy includes the off-processor memory of other processors, in addition to the hierarchy of registers, cache, and local memory on each processor.) The fundamental building blocks of the ScaLAPACK library are distributed memory versions (PBLAS) of the Level 1, 2 and 3 BLAS, and a set of Basic Linear Algebra Communication Subprograms (BLACS) for communication tasks that arise frequently in parallel linear algebra computations. In the ScaLAPACK routines, all interprocessor communication occurs within the PBLAS and the BLACS. One of the design goals of ScaLAPACK was to have the ScaLAPACK routines resemble their LAPACK equivalents as much as possible. R-RScaLAPACK: URL: http://cran.r-project.org/contrib SRPM: http://www.auroralinux.org/people/spot/R/R-RScaLAPACK-0.4.0-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/R/R-RScaLAPACK.spec R package: An R add-on package capable of carrying out parallel computation through a single function call from the R environment. It uses the high-performance ScaLAPACK library for the linear algebra computations. ==== Thanks in advance, ~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 mattdm at mattdm.org Tue Apr 19 15:18:11 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Apr 2005 11:18:11 -0400 Subject: Request for review: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <1113848032.26306.19.camel@ignacio.ignacio.lan> References: <20050418140154.GB20034@jadzia.bu.edu> <1113848032.26306.19.camel@ignacio.ignacio.lan> Message-ID: <20050419151811.GA28997@jadzia.bu.edu> On Mon, Apr 18, 2005 at 02:13:51PM -0400, Ignacio Vazquez-Abrams wrote: > Sure. When do you take a look at OpenEXR and swish-e? ;) Thanks. And we'll see how much time I end up having this week. I'm definitely interested in swish-e. > > python-ZSI: > - noarch packages should BR python, not python-devel Fixed. > "# shouldn't be installing files with .py extension into bin" > So then would it be better to install them into %{_datadir}/%{name} and > use symlinks? What's the advantage of doing it that way? > > python-SOAPpy: > ? "BSD-style"? Perhaps just "BSD" would be fine Well, != University of California, Berkeley. But yeah, I guess it does use the BSD template exactly. So, changed. > - noarch packages should BR python, not python-devel Fixed. > > python-fpconst: > - noarch packages should BR python, not python-devel Fixed. Updated packages and spec files at: Thanks again. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jdennis at redhat.com Tue Apr 19 15:20:30 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Apr 2005 11:20:30 -0400 Subject: Starting Daemons - Wiki page? In-Reply-To: <20050419133750.GA21833@nostromo.devel.redhat.com> References: <1113565937.3763.1.camel@fc4t2.mpeters.local> <20050415072655.B2566@tiki-lounge.com> <1113626359.12190.5.camel@fc4t2.mpeters.local> <1113837592.9169.8.camel@localhost.localdomain> <1113893007.24680.20.camel@fc4t2.mpeters.local> <20050419133750.GA21833@nostromo.devel.redhat.com> Message-ID: <1113924030.10777.0.camel@localhost.localdomain> On Tue, 2005-04-19 at 09:37 -0400, Bill Nottingham wrote: > Michael A. Peters (mpeters at mac.com) said: > > > Yes, this is the right approach. Bill Nottingham wrote up an internal > > > wiki page on how to handle services in spec files. Maybe we can get > > > permission to copy the contents over to the fedora wiki. > > > > I would appreciate that. > > Feel free to copy whatever. :) Done. (It could use some editing/formatting, but the info is there) -- John Dennis From bugs.michael at gmx.net Tue Apr 19 15:39:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Apr 2005 17:39:44 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419142917.GB25583@ryoko.camperquake.de> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> <20050419142917.GB25583@ryoko.camperquake.de> Message-ID: <20050419173944.0b557014.bugs.michael@gmx.net> On Tue, 19 Apr 2005 16:29:17 +0200, Ralf Ertzinger wrote: > On Tue, Apr 19, 2005 at 03:17:30PM +0200, Michael Schwendt wrote: > > > * There should be no need to hardcode the BMP input plugin path in > > the Makefile and the spec. Use this instead (and a similar thing in the > > Makefile): > > > > %define plugindir %(pkg-config bmp --variable=input_plugin_dir) > > Ah, so there it is. Is there a way to show all variables that a > given .pc file defines? Yes, "cat filename.pc". ;o) From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 15:40:17 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 17:40:17 +0200 Subject: Wiki RPM In-Reply-To: <80d7e409050418134033260a3c@mail.gmail.com> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> Message-ID: <20050419174017.276ce8e7@python2> Stephen J. Smoogen wrote : > On 4/15/05, Jeff Pitman wrote: > > On Thursday 14 April 2005 14:50, Matthias Saou wrote: > > | so I'd be more > > | than happy to review and test any packages that would be submitted. > > > > In the interim: > > http://python.org/pyvault/python/2.4/noarch/html/index_testing.html > > > > And if anyone wants to use the rest as a base for something, feel free. > > Lately, I've not had much in terms of time. > > Crap.. Sorry I have been running around dealing with otehr issues. I > will send someone what I have gotten together from Red Hat and Seth's > rpms. I'm getting really desperate for a MoinMoin package, so I may very well adapt Jeff's rpm. I tried rebuilding it, but always get : "error: option -- record-rpm not recognized" on FC2, FC3 & FC Dev. Jeff: Is this some option added in your python packages? Is it maybe provided by a module not listed as a build requirement? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.52 1.51 1.54 From skvidal at phy.duke.edu Tue Apr 19 15:45:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 19 Apr 2005 11:45:40 -0400 Subject: Wiki RPM In-Reply-To: <20050419174017.276ce8e7@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> Message-ID: <1113925540.15629.20.camel@cutter> > I'm getting really desperate for a MoinMoin package, so I may very well > adapt Jeff's rpm. I tried rebuilding it, but always get : "error: option -- > record-rpm not recognized" on FC2, FC3 & FC Dev. > > Jeff: Is this some option added in your python packages? Is it maybe > provided by a module not listed as a build requirement? > Matthias look here: http://linux.duke.edu/~skvidal/RPMS/foo/ the 1.3.3 one is the latest I have. Icon built these - I modifed them - the ext-macro is just a local package I have that packages up the external macro scripts we needed. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 16:00:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 18:00:11 +0200 Subject: Wiki RPM In-Reply-To: <1113925540.15629.20.camel@cutter> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> <1113925540.15629.20.camel@cutter> Message-ID: <20050419180011.13f4aaba@python2> seth vidal wrote : > Matthias look here: > > http://linux.duke.edu/~skvidal/RPMS/foo/ > > the 1.3.3 one is the latest I have. How 'bout I take a look at the three packages that have been pointed out so far and merge all the relevant bits into one? Florian included a nice README.redhat file with the commands and apache config bits required to get MoinMoin working in no time, which is definitely a nice thing. I'll take a look at the Duke package now. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.41 0.79 0.98 From laroche at redhat.com Tue Apr 19 16:02:21 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 19 Apr 2005 18:02:21 +0200 Subject: Wiki RPM In-Reply-To: <20050419180011.13f4aaba@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> <1113925540.15629.20.camel@cutter> <20050419180011.13f4aaba@python2> Message-ID: <20050419160221.GA7626@dudweiler.stuttgart.redhat.com> > How 'bout I take a look at the three packages that have been pointed out > so far and merge all the relevant bits into one? Florian included a nice Great. Thanks, Florian La Roche From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 16:10:54 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 18:10:54 +0200 Subject: Request for review: moin (was: Re: Wiki RPM) In-Reply-To: <20050419160221.GA7626@dudweiler.stuttgart.redhat.com> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> <1113925540.15629.20.camel@cutter> <20050419180011.13f4aaba@python2> <20050419160221.GA7626@dudweiler.stuttgart.redhat.com> Message-ID: <20050419181054.28f76b8b@python2> Hi, So, attached is a moin.spec file mainly based on Florian's one, with a few fixes that seemed obvious after looking at Jeff's (missing buildroot removal in %install, better summary and description). BTW, should some "Requires: python-abi = %{pyver}" and related macros be included or does the new FC4 magic take care of that for us now? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.33 0.68 0.84 -------------- next part -------------- A non-text attachment was scrubbed... Name: moin.spec Type: application/octet-stream Size: 1669 bytes Desc: not available URL: From mpeters at mac.com Tue Apr 19 16:13:47 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 19 Apr 2005 09:13:47 -0700 Subject: Sponsor Request: jigdo In-Reply-To: <20050419115650.7d48108d.bugs.michael@gmx.net> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <20050419115650.7d48108d.bugs.michael@gmx.net> Message-ID: <1113927227.5156.4.camel@fc4t2.mpeters.local> On Tue, 2005-04-19 at 11:56 +0200, Michael Schwendt wrote: > > No. But does it still contain so many Debian specific files and defaults? > E.g. Debian mirror lists as opposed to Fedora mirror lists? I don't find > that useful. If you want to lobby for jigdo distribution of Fedora ISOs, > the package should at least offer some experimental Fedora-specific > config defaults. I'm willing to help with that. From ivazquez at ivazquez.net Tue Apr 19 16:31:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 19 Apr 2005 12:31:44 -0400 Subject: Review Request: bazaar In-Reply-To: <4265140E.4010003@shahms.com> References: <4263D95B.3000606@shahms.com> <1113847651.26306.12.camel@ignacio.ignacio.lan> <4265140E.4010003@shahms.com> Message-ID: <1113928304.13656.40.camel@ignacio.ignacio.lan> On Tue, 2005-04-19 at 07:22 -0700, Shahms King wrote: > Ignacio Vazquez-Abrams wrote: > | On Mon, 2005-04-18 at 08:59 -0700, Shahms King wrote: > | > |>I checked in an initial package for the 'bazaar' implementation of the > |>GNU Arch revision control system. The module and package name is > |>'bazaar', I'd appreciate it if some of you kind folks would review it. > | > | > | Is the grep against build/%{name}.lang really required? > > So, would you call this reviewed? Can I send an APPROVED message to > commits, or would you like to? Go for 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 Tue Apr 19 16:34:59 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 19 Apr 2005 12:34:59 -0400 Subject: Request for review: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <20050419151811.GA28997@jadzia.bu.edu> References: <20050418140154.GB20034@jadzia.bu.edu> <1113848032.26306.19.camel@ignacio.ignacio.lan> <20050419151811.GA28997@jadzia.bu.edu> Message-ID: <1113928499.13656.44.camel@ignacio.ignacio.lan> On Tue, 2005-04-19 at 11:18 -0400, Matthew Miller wrote: > On Mon, Apr 18, 2005 at 02:13:51PM -0400, Ignacio Vazquez-Abrams wrote: > > "# shouldn't be installing files with .py extension into bin" > > So then would it be better to install them into %{_datadir}/%{name} and > > use symlinks? > > What's the advantage of doing it that way? I... don't know. I was hoping to incite some discussion about this, as I'd like to know if it's a real issue. -- 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 Tue Apr 19 17:14:00 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 19 Apr 2005 19:14:00 +0200 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> Message-ID: <0ML29c-1DNwIQ3G7a-000771@mrelayeu.kundenserver.de> On Mon, 18 Apr 2005 17:40:56 -0500, you wrote: > With regards to "Re: Fedora Individual Contributor License Agreement". > Your message could not be processed. > Reason The signature's username did not match the e-mail address on file. I have filled out the CLA and make the .asc file with $ gpg -a --sign described in the message, I got from the admin application. I was wondering, that the produced .asc file only contains a base64-encoded chunk. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Tue Apr 19 17:14:02 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 19 Apr 2005 19:14:02 +0200 Subject: Wkik-Admin Request Message-ID: <0ML29c-1DNwIR27RO-000771@mrelayeu.kundenserver.de> Hello, after the import of the INADYN package to the CVS, Ignacio Vazquez-Abrams explain me in a mail, that I need edit acces to Extras/Extras/BugzillaAdmin. Extras/CVSSyncNeeded, Extras/FC3Status, and Extras/FC4Status. on the wiki. It will be nice, if anyoune help me. My wiki name is 'JochenSchmitt' And at last, I need a sponsor for CVS access. I have create a new account on the new account managment system with the username 's4504kr'. Best Regards: Jochen Schmitt. From ed at eh3.com Tue Apr 19 17:18:08 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 19 Apr 2005 13:18:08 -0400 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK In-Reply-To: <1113921269.19436.74.camel@swoop> References: <1113921269.19436.74.camel@swoop> Message-ID: <1113931088.19567.17.camel@ernie> On Tue, 2005-04-19 at 09:34 -0500, Tom 'spot' Callaway wrote: > > Second chunk of R related packages for review, this time, I've got > lapack's cousins, blacs, and scalapack, along with the first of many > R modules, RScaLAPACK. The R modules are so similar that the spec > template is virtually identical for each module. Hi Spot, I think its great to see more math and stats packages going into Extras! Heres my review notes: === blacs === - Is "BuildRoot: %{_tmppath}/lapack-%{version}-root" OK? Honestly, I'm not an authority! It just seems odd. - Should there be a "BuildRequires: gfortran"? I can't get it to build without gfortran (eg. on an FC3 system w/g77) and its not listed in the BuildRequires Exceptions list at: http://fedoraproject.org/wiki/PackagingGuidelines - Otherwise seems to build and install without any problems though I've not yet had a chance to use it. === scalapack === - again, is "BuildRoot: %{_tmppath}/lapack-%{version}-root" OK? - again, does it need a "BuildRequires: gfortran"? - Appears to build, install, and otherwise looks OK on a freshly updated devel system (but did not actually have the time to run any of it). === R-RScaLAPACK === - It needs R-devel and "yum install R-devel" fails due to a dependency upon gcc-g77. So, perhaps R-devel needs to be updated to depend upon gcc-gfortran before trying to review R-RScaLAPACK? 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 mattdm at mattdm.org Tue Apr 19 17:31:29 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Apr 2005 13:31:29 -0400 Subject: Request for review: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <1113928499.13656.44.camel@ignacio.ignacio.lan> References: <20050418140154.GB20034@jadzia.bu.edu> <1113848032.26306.19.camel@ignacio.ignacio.lan> <20050419151811.GA28997@jadzia.bu.edu> <1113928499.13656.44.camel@ignacio.ignacio.lan> Message-ID: <20050419173129.GA3034@jadzia.bu.edu> On Tue, Apr 19, 2005 at 12:34:59PM -0400, Ignacio Vazquez-Abrams wrote: > > > So then would it be better to install them into %{_datadir}/%{name} and > > > use symlinks? > > What's the advantage of doing it that way? > I... don't know. I was hoping to incite some discussion about this, as > I'd like to know if it's a real issue. I guess this is an area where I don't have a really strong opinion. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 17:41:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 19:41:25 +0200 Subject: Request for review: moin (was: Re: Wiki RPM) In-Reply-To: <20050419181054.28f76b8b@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> <1113925540.15629.20.camel@cutter> <20050419180011.13f4aaba@python2> <20050419160221.GA7626@dudweiler.stuttgart.redhat.com> <20050419181054.28f76b8b@python2> Message-ID: <20050419194125.1840263e@python2> Eek, I forgot to attach the patch. Here it is. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.27 0.84 0.97 -------------- next part -------------- A non-text attachment was scrubbed... Name: moin-1.3-config.patch Type: application/octet-stream Size: 4146 bytes Desc: not available URL: From g.hollestelle at gmail.com Tue Apr 19 17:55:36 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Tue, 19 Apr 2005 19:55:36 +0200 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <0ML29c-1DNwIQ3G7a-000771@mrelayeu.kundenserver.de> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <0ML29c-1DNwIQ3G7a-000771@mrelayeu.kundenserver.de> Message-ID: <95da2d2905041910557cd6178a@mail.gmail.com> On 4/19/05, Jochen Schmitt wrote: > On Mon, 18 Apr 2005 17:40:56 -0500, you wrote: > > > With regards to "Re: Fedora Individual Contributor License Agreement". > > Your message could not be processed. > > Reason The signature's username did not match the e-mail address on file. > > I have filled out the CLA and make the .asc file with > > $ gpg -a --sign > > described in the message, I got from the admin application. > > I was wondering, that the produced .asc file only contains a > base64-encoded chunk. Hi Jochem, That's normal it also happend when I signed it, to view the contents use gpg --decrypt file.asc. It should show the contract followed by: gpg: Signature made ... gpg: Good signature from ... I wonder why the --clearsign option isn't used, that way the resulting file would look more like a signed document to a human reader. Greets, Gijs From tcallawa at redhat.com Tue Apr 19 18:50:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Apr 2005 13:50:16 -0500 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK In-Reply-To: <1113931088.19567.17.camel@ernie> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> Message-ID: <1113936616.19436.102.camel@swoop> On Tue, 2005-04-19 at 13:18 -0400, Ed Hill wrote: > === blacs === > - Is "BuildRoot: %{_tmppath}/lapack-%{version}-root" OK? Honestly, > I'm not an authority! It just seems odd. Whoops. Caught me. Can anyone guess which spec file I used as a base? :) > - Should there be a "BuildRequires: gfortran"? I can't get it to > build without gfortran (eg. on an FC3 system w/g77) and its not > listed in the BuildRequires Exceptions list at: > http://fedoraproject.org/wiki/PackagingGuidelines Yes, it should be there. Note that all of these packages are targeted at FC4 (devel). They could probably be made to work on FC3, if there is interest. > === scalapack === > - again, is "BuildRoot: %{_tmppath}/lapack-%{version}-root" OK? Nope. > - again, does it need a "BuildRequires: gfortran"? Yup. > - Appears to build, install, and otherwise looks OK on a freshly > updated devel system (but did not actually have the time to run any > of it). > > === R-RScaLAPACK === > - It needs R-devel and "yum install R-devel" fails due to a > dependency upon gcc-g77. So, perhaps R-devel needs to be updated > to depend upon gcc-gfortran before trying to review R-RScaLAPACK? The fc3 version of R-devel requires gcc-g77. The fc4 (devel) version requires gcc-gfortran. So, this is expected behavior on fc3. If there is demand, I can start making fc3 packages for review alongside the devel packages. Updated packages: blacs: SRPM:http://www.auroralinux.org/people/spot/R/blacs-1.1-4.src.rpm SPEC:http://www.auroralinux.org/people/spot/R/blacs.spec scalapack: SRPM:http://www.auroralinux.org/people/spot/R/scalapack-1.7-2.src.rpm SPEC:http://www.auroralinux.org/people/spot/R/scalapack.spec R-RScaLAPACK: SRPM:http://www.auroralinux.org/people/spot/R/R-RScaLAPACK-0.4.0-2.src.rpm SPEC:http://www.auroralinux.org/people/spot/R/R-RScaLAPACK.spec ~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 thm at duke.edu Tue Apr 19 19:10:47 2005 From: thm at duke.edu (Hunter Matthews) Date: Tue, 19 Apr 2005 15:10:47 -0400 Subject: Fedora Extras: Get involved more easily! In-Reply-To: References: Message-ID: <1113937847.2825.32.camel@jade.biology.duke.edu> On Mon, 2005-04-18 at 16:54, Elliot Lee wrote: > If you'd like to become a Fedora Extras developer, but the process of > getting CVS access seemed too slow before, please visit > https://admin.fedora.redhat.com/accounts/ to use the new automated system. I was one of those people. :) If you're taking suggestions on those forms, could you add a link from the field names (like userid) on the left to a page (or something) that says a little bit about what you expect? I had to ask spot if userid needed to make the WikiName or what. Once the process is complete, you might have the system include in its "welcome aboard" email either the "commit" instructions or a link to them, for us utter newbies to the process. -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet. From fedora at camperquake.de Tue Apr 19 19:21:10 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 19 Apr 2005 21:21:10 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419151730.35257143.bugs.michael@gmx.net> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> Message-ID: <20050419212110.698d558b@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > * There should be no need to hardcode the BMP input plugin path in > the Makefile and the spec. Use this instead (and a similar thing in the > Makefile): > > * $RPM_OPT_FLAGS are not accepted. You need to pass CFLAGS= to "make" > manually. I fixed the things you and Matthias suggested, new packages at http://ryoko.camperquake.de/fedora/bmp-flac/ From Jochen at herr-schmitt.de Tue Apr 19 19:27:34 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 19 Apr 2005 21:27:34 +0200 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <95da2d2905041910557cd6178a@mail.gmail.com> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <0ML29c-1DNwIQ3G7a-000771@mrelayeu.kundenserver.de> <95da2d2905041910557cd6178a@mail.gmail.com> Message-ID: On Tue, 19 Apr 2005 19:55:36 +0200, you wrote: >That's normal it also happend when I signed it, to view the contents >use gpg --decrypt file.asc. It should show the contract followed by: >gpg: Signature made ... >gpg: Good signature from ... Thank you for your answer. After I have study man gpg, it was clear, that a armor block was builded during the signing process. But this didn't explain, why the message was discarded from the admin application. I assume, that this happen, becouse the public key was not marked a trusted during the call of gpg in the admin application. If you are verify a file, which signed with a key, which is not marked as trusted, you get a message, that the authentification of the key could not be verified. Best Regards: Jochen Schmitt From jeff at ocjtech.us Tue Apr 19 19:58:10 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 19 Apr 2005 14:58:10 -0500 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> Message-ID: <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> On Mon, 2005-04-18 at 17:40 -0500, Jeffrey C. Ollie wrote: > On Mon, 2005-04-18 at 16:54 -0400, Elliot Lee wrote: > > If you'd like to become a Fedora Extras developer, but the process of > > getting CVS access seemed too slow before, please visit > > https://admin.fedora.redhat.com/accounts/ to use the new automated system. > > > > If you had sent in a request for an account to > > cvs-access at fedoraproject.org, and the account was not activated, please go > > through the application process again with the new system. It should be a > > lot quicker than before! :) > > Hmmm... Having a problem with the CLA process. First of all, the system > does not appear to handle GPG-signed email messages. Once I replied > with a non-signed email I got this back from the system: > > With regards to "Re: Fedora Individual Contributor License Agreement". > Your message could not be processed. > Reason The signature's username did not match the e-mail address on file. > > Any clue as to why this isn't working for me? Well, I think that I solved my problem. It seems that the automated system has problems with GPG keys that have multiple IDs. I changed my email address on the web pages to my old email address (which is one of the IDs of my key) and resubmitted the signed CLA. This time it went through. 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 bugs.michael at gmx.net Tue Apr 19 19:59:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Apr 2005 21:59:19 +0200 Subject: Request for review: moin (was: Re: Wiki RPM) In-Reply-To: <20050419181054.28f76b8b@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> <1113925540.15629.20.camel@cutter> <20050419180011.13f4aaba@python2> <20050419160221.GA7626@dudweiler.stuttgart.redhat.com> <20050419181054.28f76b8b@python2> Message-ID: <20050419215919.3c2b7096.bugs.michael@gmx.net> On Tue, 19 Apr 2005 18:10:54 +0200, Matthias Saou wrote: > BTW, should some "Requires: python-abi = %{pyver}" and related macros be > included or does the new FC4 magic take care of that for us now? It's automatic, but "python(abi) = ..." instead of "python-abi = ...". Nothing to worry about, though. From kaboom at oobleck.net Tue Apr 19 19:59:23 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 19 Apr 2005 15:59:23 -0400 (EDT) Subject: Fedora Extras: Get involved more easily! In-Reply-To: <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> Message-ID: On Tue, 19 Apr 2005, Jeffrey C. Ollie wrote: > Well, I think that I solved my problem. It seems that the automated > system has problems with GPG keys that have multiple IDs. I changed my > email address on the web pages to my old email address (which is one of > the IDs of my key) and resubmitted the signed CLA. This time it went > through. FWIW, my GPG key has multiple IDs and I didn't have problems signing the CLA.... later, chris From bugs.michael at gmx.net Tue Apr 19 20:23:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Apr 2005 22:23:44 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419212110.698d558b@nausicaa.camperquake.de> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> <20050419212110.698d558b@nausicaa.camperquake.de> Message-ID: <20050419222344.3da5dd23.bugs.michael@gmx.net> On Tue, 19 Apr 2005 21:21:10 +0200, Ralf Ertzinger wrote: > I fixed the things you and Matthias suggested, new packages at > http://ryoko.camperquake.de/fedora/bmp-flac/ Two blocker bugs: * Doesn't work for me. Steps to reproduce: 1. take an arbitrary .WAV file 2. encode it with "flac filename.wav" 3. load "filename.flac" into BMP Result: Invalid FLAC File: "file:///..." The reason is that the "filename" argument passed to plugin code is prefixed with "file://", which you need to strip off in the plugin callback functions. I've ported xmms-fc to BMP a week ago to have more code for testing BMP and ran into the same issue. * "Version: 2" for bmp-flac is highly questionable. Unless you plan to fork the existing code and maintain your own plugin, better start with a version lower than or equal to BMP's current 0.9.7 version and/or lower to FLAC's version (see xmms-flac). From jeff at ocjtech.us Tue Apr 19 21:31:01 2005 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 19 Apr 2005 16:31:01 -0500 Subject: Fedora Extras: Get involved more easily! In-Reply-To: References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> Message-ID: <1113946262.27689.52.camel@lt16586.campus.dmacc.edu> On Tue, 2005-04-19 at 15:59 -0400, Chris Ricker wrote: > On Tue, 19 Apr 2005, Jeffrey C. Ollie wrote: > > > Well, I think that I solved my problem. It seems that the automated > > system has problems with GPG keys that have multiple IDs. I changed my > > email address on the web pages to my old email address (which is one of > > the IDs of my key) and resubmitted the signed CLA. This time it went > > through. > > FWIW, my GPG key has multiple IDs and I didn't have problems signing the > CLA.... It may have something to do with the order of the IDs on your GPG key. In my case, I listed an email address on the web page that is listed second on my GPG key. 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 cra at WPI.EDU Tue Apr 19 21:37:11 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 19 Apr 2005 17:37:11 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <1113927227.5156.4.camel@fc4t2.mpeters.local> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <20050419115650.7d48108d.bugs.michael@gmx.net> <1113927227.5156.4.camel@fc4t2.mpeters.local> Message-ID: <20050419213711.GF4369@angus.ind.WPI.EDU> On Tue, Apr 19, 2005 at 09:13:47AM -0700, Michael A. Peters wrote: > On Tue, 2005-04-19 at 11:56 +0200, Michael Schwendt wrote: > > No. But does it still contain so many Debian specific files and defaults? > > E.g. Debian mirror lists as opposed to Fedora mirror lists? I don't find > > that useful. If you want to lobby for jigdo distribution of Fedora ISOs, > > the package should at least offer some experimental Fedora-specific > > config defaults. > > I'm willing to help with that. That would be great. I have not played with or looked at jigdo-mirror at all. I just ripped it out of the RPMs, since they were full of Debian stuff. From enrico.scholz at informatik.tu-chemnitz.de Tue Apr 19 21:17:55 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 19 Apr 2005 23:17:55 +0200 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> (Jeffrey C. Ollie's message of "Tue, 19 Apr 2005 14:58:10 -0500") References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> Message-ID: <87mzrufou4.fsf@kosh.bigo.ensc.de> jeff at ocjtech.us ("Jeffrey C. Ollie") writes: >> Hmmm... Having a problem with the CLA process. First of all, the system >> does not appear to handle GPG-signed email messages. > ... > Well, I think that I solved my problem. It seems that the automated > system has problems with GPG keys that have multiple IDs. Which keyserver is used by the system? Fedora doc refers to pgp.mit.edu which should not be used nowadays anymore as it can does not work with subkeys. A modern SKS keyserver like 'sks.keyserver.penguin.de' should be used instead of. 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 all-the-johnsons.co.uk Wed Apr 20 00:10:40 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 20 Apr 2005 01:10:40 +0100 Subject: wxWidgets and gcc4 Message-ID: <1113955840.29611.3.camel@localhost.localdomain> Hi, Is the problem with wx or with gcc that I can't get software to compile with gcc4 that requires the wx libraries? TTFN Paul -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 kaboom at oobleck.net Wed Apr 20 00:14:10 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 19 Apr 2005 20:14:10 -0400 (EDT) Subject: packages for review: openbox and friends Message-ID: openbox is a fairly minimal blackbox-derived X11 window manager obpager is a pager intended for it, but usable with most window managers obconf is a configuration utility for openbox Anyone want to review them? Thanks! later, chris From tcallawa at redhat.com Wed Apr 20 00:50:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Apr 2005 19:50:33 -0500 Subject: wxWidgets and gcc4 In-Reply-To: <1113955840.29611.3.camel@localhost.localdomain> References: <1113955840.29611.3.camel@localhost.localdomain> Message-ID: <1113958233.19436.133.camel@swoop> On Wed, 2005-04-20 at 01:10 +0100, Paul wrote: > Hi, > > Is the problem with wx or with gcc that I can't get software to compile > with gcc4 that requires the wx libraries? wx. Refer to bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154958 The issue has been fixed, but the maintainer *cough* hasn't scheduled a new devel build, or closed the ticket (or touched the ticket). ~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 dwmw2 at infradead.org Wed Apr 20 00:58:27 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Apr 2005 10:58:27 +1000 Subject: wxWidgets and gcc4 In-Reply-To: <1113958233.19436.133.camel@swoop> References: <1113955840.29611.3.camel@localhost.localdomain> <1113958233.19436.133.camel@swoop> Message-ID: <1113958708.6364.9.camel@localhost.localdomain> On Tue, 2005-04-19 at 19:50 -0500, Tom 'spot' Callaway wrote: > The issue has been fixed, but the maintainer *cough* hasn't scheduled a > new devel build, or closed the ticket (or touched the ticket). If Extras is going to be workable, this kind of thing needs not to happen. I don't want to pick on one maintainer in particular -- I'm fairly crap as a maintainer too at times. But maintenance internally is a little more of a shared task, so I know that if I'm slack, someone will often fix stuff up for me anyway. If the package is important enough that someone else actually cares, then let them fix it without waiting for the 'real' maintainer. If so few people care about the package that it has to wait for the maintainer to get round to it, then perhaps that package isn't really something that should be in Extras? P'raps we need a two-tier Extras -- a first tier for those packages which are maintained along similar lines to the packages in Core, and a second for the more esoteric and less actively maintained packages? -- dwmw2 From pedro.lamarao at mndfck.org Wed Apr 20 01:59:26 2005 From: pedro.lamarao at mndfck.org (=?UTF-8?B?UGVkcm8gTGFtYXLDo28=?=) Date: Tue, 19 Apr 2005 22:59:26 -0300 Subject: Request for sponsor: libotr and gaim-otr Message-ID: <4265B77E.7010806@mndfck.org> >From http://www.cypherpunks.ca/otr/, summarized: Off-the-Record (OTR) Messaging allows you to have private conversations over instant messaging by providing Encryption, Authentication, Deniability and Perfect Forward Secrecy. The packages are a library implementing OTR, and a plugin for gaim. http://mndfck.org/~pedro.lamarao/fedora/libotr-2.0.1-2.src.rpm http://mndfck.org/~pedro.lamarao/fedora/gaim-otr-2.0.1-2.src.rpm This is my first attempt at this, so, education is welcome. :) -- Pedro Lamar?o From adrian at lisas.de Wed Apr 20 05:29:15 2005 From: adrian at lisas.de (Adrian Reber) Date: Wed, 20 Apr 2005 07:29:15 +0200 Subject: packages for review: openbox and friends In-Reply-To: References: Message-ID: <20050420052915.GA11961@lisas.de> On Tue, Apr 19, 2005 at 08:14:10PM -0400, Chris Ricker wrote: > > > 404 for all three packages Adrian From sopwith at redhat.com Wed Apr 20 06:15:14 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 20 Apr 2005 02:15:14 -0400 (EDT) Subject: Maintainer for bonsai/lxr/tinderbox? Message-ID: I realize these are tools that about three people want packages of, but if anyone would like to take them as seeds for Fedora Extras packages, I've got .src.rpm's for bonsai/lxr/tinderbox/registry. Best, -- Elliot From fedora at camperquake.de Wed Apr 20 10:34:13 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 20 Apr 2005 12:34:13 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <20050419222344.3da5dd23.bugs.michael@gmx.net> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> <20050419212110.698d558b@nausicaa.camperquake.de> <20050419222344.3da5dd23.bugs.michael@gmx.net> Message-ID: <20050420123413.78bbee25@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > * Doesn't work for me. Steps to reproduce: Damn. OK, I wanted to rewrite this thing from scratch anyway, but I had hoped that the hacked xmms-flac version would do for a while. Consider the package request retracted until I have something that works with gnome-vfs. -- 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 wtogami at redhat.com Wed Apr 20 11:55:41 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 01:55:41 -1000 Subject: Maintainer for bonsai/lxr/tinderbox? In-Reply-To: References: Message-ID: <4266433D.3050305@redhat.com> Elliot Lee wrote: > I realize these are tools that about three people want packages of, but if > anyone would like to take them as seeds for Fedora Extras packages, I've > got .src.rpm's for bonsai/lxr/tinderbox/registry. > > Best, > -- Elliot Go ahead and import them and see if any developers tear them apart in package review. Whoever tears the most gets to keep the pieces? =) Warren Togami wtogami at redhat.com From kaboom at oobleck.net Wed Apr 20 12:12:35 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 20 Apr 2005 08:12:35 -0400 (EDT) Subject: packages for review: openbox and friends In-Reply-To: <20050420052915.GA11961@lisas.de> References: <20050420052915.GA11961@lisas.de> Message-ID: On Wed, 20 Apr 2005, Adrian Reber wrote: > On Tue, Apr 19, 2005 at 08:14:10PM -0400, Chris Ricker wrote: > > > > > > > > 404 for all three packages Sorry, wrong URLs later, chris From wtogami at redhat.com Wed Apr 20 12:12:36 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 02:12:36 -1000 Subject: Requires, Prereq, and Requires(pre) In-Reply-To: <42664513.6010001@redhat.de> References: <200504201053.j3KArxR1019806@cvs-int.fedora.redhat.com> <1113996503.13656.88.camel@ignacio.ignacio.lan> <42664513.6010001@redhat.de> Message-ID: <42664734.1010903@redhat.com> Karsten Hopp wrote: > Ignacio Vazquez-Abrams wrote: > ... > >> >> >>> Prereq: %{_prefix}/X11R6/bin/mkfontdir >>> BuildPreReq: ncurses-devel readline-devel glibc-devel >> >> >> >> These should be "Requires(pre)" and "BuildRequires" respectively. And >> you can drop the glibc-devel. > > > Is there a final decision on that or is that just your preference ? > We have LOTS of packages in FC which use Prereq: and BuildPreReq: > instead of > Requires(pre) and BuildRequires(pre). There is no difference between BuildRequires and BuildPrereq. BuildRequires(pre) is simply silly. However the story behind Requires, Prereq, and Requires(pre) is more complicated. Apparently Requires and Prereq are now equivalent, but Requires(pre) is not. This really needs to be explained with detailed examples and documented once and for all in the Wiki because this is repeatedly a source of confusion. In most cases "Requires" is all you need, there is no benefit to using "Prereq", however there are cases where Requires(pre) is needed to break a dependency loop. However this may not be the truth for all distributions, because apparently the behavior of Requires/Prereq changed recently. This historical behavior and when things changed should be documented too. I don't know the entire story myself. Warren Togami wtogami at redhat.com From dwmw2 at infradead.org Wed Apr 20 13:28:41 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Apr 2005 23:28:41 +1000 Subject: ulog not on ppc? Message-ID: <1114003722.5877.28.camel@localhost.localdomain> Why is the ulog build requested in the wiki for only i386 and x86_64? It appears to build fine on PPC -- what's the problem? We _really_ ought to have a policy of requiring bug numbers to be given for any arch exclusion. -- dwmw2 From skvidal at phy.duke.edu Wed Apr 20 13:33:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 20 Apr 2005 09:33:40 -0400 Subject: ulog not on ppc? In-Reply-To: <1114003722.5877.28.camel@localhost.localdomain> References: <1114003722.5877.28.camel@localhost.localdomain> Message-ID: <1114004020.15629.57.camel@cutter> On Wed, 2005-04-20 at 23:28 +1000, David Woodhouse wrote: > Why is the ulog build requested in the wiki for only i386 and x86_64? It > appears to build fine on PPC -- what's the problem? > > We _really_ ought to have a policy of requiring bug numbers to be given > for any arch exclusion. I'm betting it's just a user failing to include ppc in the build request. It's not the first time. -sv From dwmw2 at infradead.org Wed Apr 20 14:03:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Apr 2005 00:03:22 +1000 Subject: ulog not on ppc? In-Reply-To: <1114004020.15629.57.camel@cutter> References: <1114003722.5877.28.camel@localhost.localdomain> <1114004020.15629.57.camel@cutter> Message-ID: <1114005803.5877.33.camel@localhost.localdomain> On Wed, 2005-04-20 at 09:33 -0400, seth vidal wrote: > I'm betting it's just a user failing to include ppc in the build > request. It's not the first time. Perhaps -- but since most packagers don't specify an arch to build when it's to be built for all arches, I figured it was best to ask rather than just change it. -- dwmw2 From bugs.michael at gmx.net Wed Apr 20 14:11:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 20 Apr 2005 16:11:10 +0200 Subject: ulog not on ppc? In-Reply-To: <1114005803.5877.33.camel@localhost.localdomain> References: <1114003722.5877.28.camel@localhost.localdomain> <1114004020.15629.57.camel@cutter> <1114005803.5877.33.camel@localhost.localdomain> Message-ID: <20050420161110.241c5ebb.bugs.michael@gmx.net> On Thu, 21 Apr 2005 00:03:22 +1000, David Woodhouse wrote: > On Wed, 2005-04-20 at 09:33 -0400, seth vidal wrote: > > I'm betting it's just a user failing to include ppc in the build > > request. It's not the first time. > > Perhaps -- but since most packagers don't specify an arch to build when > it's to be built for all arches, I figured it was best to ask rather > than just change it. That's misinterpretation. So far, most packagers have had to specify "(i386, x86_64)" explicitly. It's a recent change that no arch in brackets means to build for all archs. From gauret at free.fr Wed Apr 20 15:04:42 2005 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 20 Apr 2005 17:04:42 +0200 Subject: ulog not on ppc? In-Reply-To: <1114004020.15629.57.camel@cutter> References: <1114003722.5877.28.camel@localhost.localdomain> <1114004020.15629.57.camel@cutter> Message-ID: <200504201704.46711.gauret@free.fr> Le Mercredi 20 Avril 2005 15:33, seth vidal a ?crit : > I'm betting it's just a user failing to include ppc in the build > request. It's not the first time. Exactly. Sorry about that Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr "Make everything as simple as possible, but not simpler." -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 220 bytes Desc: not available URL: From ivazquez at ivazquez.net Wed Apr 20 15:09:01 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 20 Apr 2005 11:09:01 -0400 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <1113906578.13656.25.camel@ignacio.ignacio.lan> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> Message-ID: <1114009741.13656.92.camel@ignacio.ignacio.lan> On Tue, 2005-04-19 at 06:29 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-19 at 11:47 +0200, Michael Schwendt wrote: > > On Tue, 19 Apr 2005 01:32:41 -0400, Ignacio Vazquez-Abrams wrote: > > > > > sqlite: Library that implements an embeddable SQL database engine > > > > > > Imported from Rawhide and release-dropped to maintain upgradeability to > > > FC4. > > > > > > Maintainer for FE3: Ignacio Vazquez-Abrams > > > > Why? > > > > What have you planned to do with SQLite v3 in FE3? Are you aware that this > > major upgrade breaks the SQLite ABI/API and hence breaks compatibility > > with other packages in FE3? Fortunately, we don't have many sqlite > > dependencies in FE3. But "python-sqlite" and "kannel" now would need an > > update, too. > > You are of course correct, but this will have to be dealt with sooner or > later. Better now while we have some time rather than later when FC4 is > out and upgrading is borked. In the meantime I'll hold off on building > the FC3 packages so that we can do it properly. > > The question at this point becomes whether we should patch kannel for > sqlite 3 or create a sqlite2 package (python-sqlite for sqlite 3 already > exists in Rawhide and can just be imported). > > Also, there's php-pecl-sqlite. It has its own private copy of libsqlite, > but are the file formats the same between sqlite 2.8 and 3? So after some thinking here then is my plan of attack: 1) Reimport the sqlite-2.8.16-1 package as sqlite2-2.8.16-1. 2) Provide a patch for kannel for it to use sqlite2. 3) Reimport the python-sqlite package as python-sqlite2 and have it obsolete anything older than or equal to the current python-sqlite package. 4) Import the python-sqlite package from Rawhide and have the devel branch pruned once it's synced for FC3. Naturally I hope to involve the current sqlite 2.8, kannel, and python- sqlite maintainers (Panu Matilainen, Matthias Saou, and Thomas Vander Stichele respectively) in any relevant steps. I am also willing to take maintainership of the new python-sqlite package if so desired. I realize that python-sqlite2 and python-sqlite won't be parallel- installable. I don't have an easy answer for that. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 20 15:19:31 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 20 Apr 2005 17:19:31 +0200 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <1114009741.13656.92.camel@ignacio.ignacio.lan> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> Message-ID: <20050420171931.5be107c5@python2> Ignacio Vazquez-Abrams wrote : > So after some thinking here then is my plan of attack: > > 1) Reimport the sqlite-2.8.16-1 package as sqlite2-2.8.16-1. > 2) Provide a patch for kannel for it to use sqlite2. > 3) Reimport the python-sqlite package as python-sqlite2 and have it > obsolete anything older than or equal to the current python-sqlite > package. > 4) Import the python-sqlite package from Rawhide and have the devel > branch pruned once it's synced for FC3. Silly question : Why not just stick with sqlite 2.x in FC3 and concentrate on providing a working upgrade path for FC4? (like have an sqlite2 obsoleting sqlite <= 2.x, rebuild as many packages against sqlite 3 if that's possible w/ easy fixes or patches or updates...) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.12 0.25 0.61 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 20 15:28:51 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 20 Apr 2005 17:28:51 +0200 Subject: Request for review : bmp-itouch Message-ID: <20050420172851.11cb427e@python2> Hi, I've packaged a Beep Media Player plugin for multimedia keyboard keys (volume, playback etc.). I can currently configure the plugin properly, but when I try to enable it the program crashes with this X11 error : The error was 'BadAccess (attempt to access private resource denied)'. The plugin is probably doing something wrong, I'm going to report this to the author. In the meantime the spec can be reviewed... or if someone wants to poke at it to suggest a fix... ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.48 0.49 0.53 From ville.skytta at iki.fi Wed Apr 20 15:45:06 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 20 Apr 2005 18:45:06 +0300 Subject: Requires, Prereq, and Requires(pre) In-Reply-To: <42664734.1010903@redhat.com> References: <200504201053.j3KArxR1019806@cvs-int.fedora.redhat.com> <1113996503.13656.88.camel@ignacio.ignacio.lan> <42664513.6010001@redhat.de> <42664734.1010903@redhat.com> Message-ID: <1114011906.6812.193.camel@bobcat.mine.nu> On Wed, 2005-04-20 at 02:12 -1000, Warren Togami wrote: > However the story behind Requires, Prereq, and Requires(pre) is more > complicated. Apparently Requires and Prereq are now equivalent, Rumoured to be so, but practical testing with the plain old rpm CLI shows that PreReq still possesses some of the dep loop breaking magic. I tested this last week on a FC4t2 box, with enough repetitions so it cannot be attributed to just being lucky. Note: PreReq no longer seems to affect plain "yum install", or in a more generic manner, I guess rpmlib does not make a distinction between Requires and PreReq. Why the CLI still does is beyond me. > but > Requires(pre) is not. This really needs to be explained with detailed > examples and documented once and for all in the Wiki because this is > repeatedly a source of confusion. FWIW, I've already documented my understanding of this stuff in the development version of Maximum RPM, see especially "Fine Grained Dependencies", "The PreReq Tag" and "Context Marked Dependencies" at http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html It does seem to need a slight update regarding the supposedly changed PreReq semantics in rpmlib, see above. And the blurb about erasure ordering is inaccurate, I'll look into improving it. From jwboyer at jdub.homelinux.org Wed Apr 20 15:53:59 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Apr 2005 10:53:59 -0500 Subject: Fedora Extras: Get involved more easily! In-Reply-To: References: Message-ID: <20050420155359.GA10631@yoda.jdub.homelinux.org> On Mon, Apr 18, 2005 at 04:54:05PM -0400, Elliot Lee wrote: > If you'd like to become a Fedora Extras developer, but the process of > getting CVS access seemed too slow before, please visit > https://admin.fedora.redhat.com/accounts/ to use the new automated system. > > If you had sent in a request for an account to > cvs-access at fedoraproject.org, and the account was not activated, please go > through the application process again with the new system. It should be a > lot quicker than before! :) Ok, I asked around a bit to make sure the "... or any RH engineer" statement as to who can be a sponsor was still true and everyone seems to think so. But it seems that all of those people don't have the right permissions to do this. In my specific case, David Woodhouse is my sponsor but he doesn't have authority to approve my CVS access. Just thought I would point this out in case others were having a similar problem. Elliot, can we get this fixed soon? thx, josh From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 20 16:17:53 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 20 Apr 2005 18:17:53 +0200 Subject: Request for review : bmp-itouch In-Reply-To: <20050420172851.11cb427e@python2> References: <20050420172851.11cb427e@python2> Message-ID: <20050420181753.0356bbd2@python2> 1) Coffee time... forgot to post the URL to the packages. (*slap*) 2) I just tested "unstable" 1.1.0, which works great and has an option to use the multimedia keys settings from GNOME directly. http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/4/ Please review the 1.1.0 package, as it seems to work nicely. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.17 0.44 0.64 From bugs.michael at gmx.net Wed Apr 20 16:39:10 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 20 Apr 2005 18:39:10 +0200 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <20050420171931.5be107c5@python2> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> Message-ID: <20050420183910.11226215.bugs.michael@gmx.net> On Wed, 20 Apr 2005 17:19:31 +0200, Matthias Saou wrote: > Ignacio Vazquez-Abrams wrote : > > > So after some thinking here then is my plan of attack: > > > > 1) Reimport the sqlite-2.8.16-1 package as sqlite2-2.8.16-1. > > 2) Provide a patch for kannel for it to use sqlite2. > > 3) Reimport the python-sqlite package as python-sqlite2 and have it > > obsolete anything older than or equal to the current python-sqlite > > package. > > 4) Import the python-sqlite package from Rawhide and have the devel > > branch pruned once it's synced for FC3. Re 4) there is a python-sqlite in FC-3 branch already and it's for the v2 sqlite version. > Silly question : Why not just stick with sqlite 2.x in FC3 and concentrate > on providing a working upgrade path for FC4? (like have an sqlite2 > obsoleting sqlite <= 2.x, rebuild as many packages against sqlite 3 if > that's possible w/ easy fixes or patches or updates...) Right. And the question is not silly. I find it natural to develop and prepare for FC4 and only do major version upgrades for FE3 if there is demand [in form of package dependencies]. From skvidal at phy.duke.edu Wed Apr 20 18:15:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 20 Apr 2005 14:15:47 -0400 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <20050420171931.5be107c5@python2> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> Message-ID: <1114020947.23497.5.camel@cutter> > Silly question : Why not just stick with sqlite 2.x in FC3 and concentrate > on providing a working upgrade path for FC4? (like have an sqlite2 > obsoleting sqlite <= 2.x, rebuild as many packages against sqlite 3 if > that's possible w/ easy fixes or patches or updates...) +1 -sv From wtogami at redhat.com Wed Apr 20 18:12:49 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 20 Apr 2005 08:12:49 -1000 Subject: ulog not on ppc? In-Reply-To: <1114003722.5877.28.camel@localhost.localdomain> References: <1114003722.5877.28.camel@localhost.localdomain> Message-ID: <42669BA1.3070507@redhat.com> David Woodhouse wrote: > Why is the ulog build requested in the wiki for only i386 and x86_64? It > appears to build fine on PPC -- what's the problem? > > We _really_ ought to have a policy of requiring bug numbers to be given > for any arch exclusion. > Until we have a feasible way of giving arch login accounts for testing purposes to anybody, we cannot possibly expect blocking on archs. Unless you want dozens of bugs filed "not built on x86_64 and ppc because it is untested"? Warren Togami wtogami at redhat.com From byte at aeon.com.my Wed Apr 20 23:28:36 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 21 Apr 2005 09:28:36 +1000 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <20050420155359.GA10631@yoda.jdub.homelinux.org> References: <20050420155359.GA10631@yoda.jdub.homelinux.org> Message-ID: <1114039716.3900.22.camel@arena.soho.bytebot.net> On Wed, 2005-04-20 at 10:53 -0500, Josh Boyer wrote: Firstly, do not CC fedora-announce-list > Ok, I asked around a bit to make sure the "... or any RH engineer" statement > as to who can be a sponsor was still true and everyone seems to think so. But > it seems that all of those people don't have the right permissions to do this. If that is the case, then http://fedoraproject.org/wiki/Extras_2fContributors needs to be updated to reflect this "... any RH engineer" needs to be a "trusted" contributor then -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From jwboyer at jdub.homelinux.org Wed Apr 20 23:55:19 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Apr 2005 18:55:19 -0500 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <1114039716.3900.22.camel@arena.soho.bytebot.net> References: <20050420155359.GA10631@yoda.jdub.homelinux.org> <1114039716.3900.22.camel@arena.soho.bytebot.net> Message-ID: <1114041319.11041.3.camel@jdub.homelinux.org> On Thu, 2005-04-21 at 09:28 +1000, Colin Charles wrote: > On Wed, 2005-04-20 at 10:53 -0500, Josh Boyer wrote: > > Firstly, do not CC fedora-announce-list Sorry. I'm still learning mutt and hit the wrong key. > > > Ok, I asked around a bit to make sure the "... or any RH engineer" statement > > as to who can be a sponsor was still true and everyone seems to think so. But > > it seems that all of those people don't have the right permissions to do this. > > If that is the case, then > http://fedoraproject.org/wiki/Extras_2fContributors needs to be updated > to reflect this > > "... any RH engineer" needs to be a "trusted" contributor then Right. And in order to work with the new tool, they also have to create a valid account and get assigned the correct permissions. So it's still a manual step I think. They could be added at that time perhaps. josh From ivazquez at ivazquez.net Thu Apr 21 00:25:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 20 Apr 2005 20:25:39 -0400 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <20050420183910.11226215.bugs.michael@gmx.net> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> <20050420183910.11226215.bugs.michael@gmx.net> Message-ID: <1114043139.13656.101.camel@ignacio.ignacio.lan> On Wed, 2005-04-20 at 18:39 +0200, Michael Schwendt wrote: > On Wed, 20 Apr 2005 17:19:31 +0200, Matthias Saou wrote: > > > Ignacio Vazquez-Abrams wrote : > > > > > So after some thinking here then is my plan of attack: > > > > > > 1) Reimport the sqlite-2.8.16-1 package as sqlite2-2.8.16-1. > > > 2) Provide a patch for kannel for it to use sqlite2. > > > 3) Reimport the python-sqlite package as python-sqlite2 and have it > > > obsolete anything older than or equal to the current python-sqlite > > > package. > > > 4) Import the python-sqlite package from Rawhide and have the devel > > > branch pruned once it's synced for FC3. > > Re 4) there is a python-sqlite in FC-3 branch already and it's for > the v2 sqlite version. Yes, hence step 3. On Wed, 2005-04-20 at 17:19:31 +0200, Matthias Saou wrote: > Silly question : Why not just stick with sqlite 2.x in FC3 and concentrate > on providing a working upgrade path for FC4? (like have an sqlite2 > obsoleting sqlite <= 2.x, rebuild as many packages against sqlite 3 if > that's possible w/ easy fixes or patches or updates...) That's what I had intended, it simply slipped my mind to mention it in step 1. On Wed, 2005-04-20 at 18:39 +0200, Michael Schwendt wrote: > Right. And the question is not silly. I find it natural to develop and > prepare for FC4 and only do major version upgrades for FE3 if there is > demand [in form of package dependencies]. As you had mentioned yourself in f-e-c, "the sudden appearance of sqlite v3 in Rawhide has created chaos", and I'm just trying to help clean it up. If it isn't dealt with soon then it will be too late, and anyone that has kannel or moodss installed will be unable to cleanly upgrade to FC4 without manual intervention. Now, shall I proceed with the creation and import of a sqlite2 package that obsoletes sqlite < 3? -- 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 jwboyer at jdub.homelinux.org Thu Apr 21 00:36:20 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Apr 2005 19:36:20 -0500 Subject: Request for review (again?): quilt Message-ID: <1114043780.11041.12.camel@jdub.homelinux.org> Hi, I've imported the quilt package into CVS now. It's already gone through a review from a couple of folks a while back, but I thought I would post another review just to be sure I followed the process. For those that don't use CVS for some reason, the packages and spec file can be found at: http://jdub.homelinux.org/files/ I'd like to get this into the automated builds soon, so if you have comments please let me know. thx, josh From jwboyer at jdub.homelinux.org Thu Apr 21 00:44:53 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Apr 2005 19:44:53 -0500 Subject: Wiki edit access Message-ID: <1114044294.11041.16.camel@jdub.homelinux.org> Hi, I've imported the quilt package into CVS and need edit access the BugzillaAdmin, CVSSyncNeeded, etc. pages. My wiki name is "JoshBoyer". Could someone give me a hand? thx, josh From jfontain at free.fr Thu Apr 21 01:30:11 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 21 Apr 2005 03:30:11 +0200 Subject: sqlite update plans In-Reply-To: <1114043139.13656.101.camel@ignacio.ignacio.lan> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> <20050420183910.11226215.bugs.michael@gmx.net> <1114043139.13656.101.camel@ignacio.ignacio.lan> Message-ID: <42670223.5070608@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: > If it isn't dealt with soon then it will be too late, and anyone > that has kannel or moodss installed will be unable to cleanly > upgrade to FC4 without manual intervention. To clarify things, moodss can use either sqlite 2 or sqlite 3, but the sqlite package in rawhide no longer includes the required Tcl interface probably because of a bug, to which I suggested (not taken into account yet) a fix in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150960 Anything I can do to help? Thanks for you efforts! Jeean-Luc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCZwIjkG/MMvcT1qQRAoSfAKC2GgNHAVL1hugdbRWP5Pl6eDqu/gCdF9Vt 94pLsf2qCv+mU6nsk1MrKBs= =PLND -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Thu Apr 21 07:25:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 03:25:23 -0400 Subject: sqlite update plans In-Reply-To: <42670223.5070608@free.fr> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> <20050420183910.11226215.bugs.michael@gmx.net> <1114043139.13656.101.camel@ignacio.ignacio.lan> <42670223.5070608@free.fr> Message-ID: <1114068323.13656.116.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 03:30 +0200, Jean-Luc Fontaine wrote: > Ignacio Vazquez-Abrams wrote: > > > If it isn't dealt with soon then it will be too late, and anyone > > that has kannel or moodss installed will be unable to cleanly > > upgrade to FC4 without manual intervention. > > To clarify things, moodss can use either sqlite 2 or sqlite 3, but the > sqlite package in rawhide no longer includes the required Tcl > interface probably because of a bug, to which I suggested (not taken > into account yet) a fix in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150960 > Anything I can do to help? Well, I wouldn't recommend having moodss use sqlite 3 until the Core package is fixed, so moving it to sqlite2 would be best, assuming anyone wants anything done about the upgrade problem at all. -- 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 malists at epon.ro Thu Apr 21 07:45:15 2005 From: malists at epon.ro (Marius Andreiana) Date: Thu, 21 Apr 2005 10:45:15 +0300 Subject: development: alsaplayer needs rebuild Message-ID: <1114069515.2958.12.camel@marte.biciclete.ro> I wanted to fill this in bugzilla, but there's no alsaplayer package at https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% 20Extras& ---> Downloading header for alsaplayer to pack into transaction set. alsaplayer-0.99.76-3.i386 100% |=========================| 23 kB 00:00 ---> Package alsaplayer.i386 0:0.99.76-3 set to be updated --> Running transaction check --> Processing Dependency: libFLAC.so.4 for package: alsaplayer --> Processing Dependency: libOggFLAC.so.1 for package: alsaplayer --> Finished Dependency Resolution Error: Missing Dependency: libFLAC.so.4 is needed by package alsaplayer Error: Missing Dependency: libOggFLAC.so.1 is needed by package alsaplayer [root at marte ~]# locate libFLAC.so. /usr/lib/libFLAC.so.7.0.0 /usr/lib/libFLAC.so.7 Thanks, -- Marius Andreiana Epon -- future-proof business applications http://www.epon.ro From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 21 07:51:51 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 21 Apr 2005 09:51:51 +0200 Subject: development: alsaplayer needs rebuild In-Reply-To: <1114069515.2958.12.camel@marte.biciclete.ro> References: <1114069515.2958.12.camel@marte.biciclete.ro> Message-ID: <20050421095151.1cca7137@python2> Marius Andreiana wrote : > I wanted to fill this in bugzilla, but there's no alsaplayer package at > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% > 20Extras& That's because it went "bye bye" :-/ It requires to be built with libmad to be able to play mp3's, so the easiest was to just drop it and let it be provided from elsewhere. If you really want to try to have it back in Extras, take a look at how hard it would be to just disable the mp3 support in the main package (no need to even patch code out it seems) and provide the libmad decoding part from elsewhere (I don't remember if alsaplayer is modular, though). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.03 0.06 0.07 From malists at epon.ro Thu Apr 21 08:02:06 2005 From: malists at epon.ro (Marius Andreiana) Date: Thu, 21 Apr 2005 11:02:06 +0300 Subject: development: alsaplayer needs rebuild In-Reply-To: <20050421095151.1cca7137@python2> References: <1114069515.2958.12.camel@marte.biciclete.ro> <20050421095151.1cca7137@python2> Message-ID: <1114070526.2958.15.camel@marte.biciclete.ro> On Thu, 2005-04-21 at 09:51 +0200, Matthias Saou wrote: > That's because it went "bye bye" :-/ ok with me, but it's still listed in development: # yum list 'alsa*' Setting up repositories development 100% |=========================| 1.1 kB 00:00 extras-development 100% |=========================| 951 B 00:00 Reading repository metadata in from local files ... alsaplayer.i386 0.99.76-3 extras-developme -- Marius Andreiana Epon -- future-proof business applications http://www.epon.ro From fedora at leemhuis.info Thu Apr 21 08:05:11 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Apr 2005 10:05:11 +0200 Subject: development: alsaplayer needs rebuild In-Reply-To: <20050421095151.1cca7137@python2> References: <1114069515.2958.12.camel@marte.biciclete.ro> <20050421095151.1cca7137@python2> Message-ID: <1114070711.4382.14.camel@thl.ct.heise.de> Am Donnerstag, den 21.04.2005, 09:51 +0200 schrieb Matthias Saou: > Marius Andreiana wrote : > > > I wanted to fill this in bugzilla, but there's no alsaplayer package at > > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% > > 20Extras& > > That's because it went "bye bye" :-/ > It requires to be built with libmad to be able to play mp3's, so the > easiest was to just drop it and let it be provided from elsewhere. If you > really want to try to have it back in Extras, take a look at how hard it > would be to just disable the mp3 support in the main package (no need to > even patch code out it seems) and provide the libmad decoding part from > elsewhere (I don't remember if alsaplayer is modular, though). Matthias, why was it not removed from the rpm repositories? It's still there and the old package even found it's way into devel -- maybe we should place a remove request on http://www.fedoraproject.org/wiki/Extras_2fFC3Status and of course one on http://www.fedoraproject.org/wiki/Extras_2fFC4Status CU thl From jfontain at free.fr Thu Apr 21 09:24:02 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 21 Apr 2005 11:24:02 +0200 Subject: sqlite update plans In-Reply-To: <1114068323.13656.116.camel@ignacio.ignacio.lan> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> <20050420183910.11226215.bugs.michael@gmx.net> <1114043139.13656.101.camel@ignacio.ignacio.lan> <42670223.5070608@free.fr> <1114068323.13656.116.camel@ignacio.ignacio.lan> Message-ID: <42677132.5000803@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-21 at 03:30 +0200, Jean-Luc Fontaine wrote: > >> To clarify things, moodss can use either sqlite 2 or sqlite 3, >> but the sqlite package in rawhide no longer includes the required >> Tcl interface probably because of a bug, to which I suggested >> (not taken into account yet) a fix in >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150960 >> Anything I can do to help? > > > Well, I wouldn't recommend having moodss use sqlite 3 until the > Core package is fixed, so moving it to sqlite2 would be best, > assuming anyone wants anything done about the upgrade problem at > all. Agreed. The next release will therefore require sqlite2. Thanks. Jean-Luc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCZ3EykG/MMvcT1qQRAgu3AJ4ubZXK9X/fTf+eE/rjOdx1YXISrQCdGvG2 71qtV0NxcgtHGkdzWvCpxts= =rPJJ -----END PGP SIGNATURE----- From bugs.michael at gmx.net Thu Apr 21 10:05:23 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 21 Apr 2005 12:05:23 +0200 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <1114043139.13656.101.camel@ignacio.ignacio.lan> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> <20050420183910.11226215.bugs.michael@gmx.net> <1114043139.13656.101.camel@ignacio.ignacio.lan> Message-ID: <20050421120523.4dc5d3b4.bugs.michael@gmx.net> On Wed, 20 Apr 2005 20:25:39 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-20 at 18:39 +0200, Michael Schwendt wrote: > > On Wed, 20 Apr 2005 17:19:31 +0200, Matthias Saou wrote: > > > > > Ignacio Vazquez-Abrams wrote : > > > > > > > So after some thinking here then is my plan of attack: > > > > > > > > 1) Reimport the sqlite-2.8.16-1 package as sqlite2-2.8.16-1. > > > > 2) Provide a patch for kannel for it to use sqlite2. > > > > 3) Reimport the python-sqlite package as python-sqlite2 and have it > > > > obsolete anything older than or equal to the current python-sqlite > > > > package. > > > > 4) Import the python-sqlite package from Rawhide and have the devel > > > > branch pruned once it's synced for FC3. > > > > Re 4) there is a python-sqlite in FC-3 branch already and it's for > > the v2 sqlite version. > > Yes, hence step 3. Can we let the FC-3 branch rest in peace until everything is sorted out in "devel"? That's all I would like to recommend. > On Wed, 2005-04-20 at 18:39 +0200, Michael Schwendt wrote: > > Right. And the question is not silly. I find it natural to develop and > > prepare for FC4 and only do major version upgrades for FE3 if there is > > demand [in form of package dependencies]. > > As you had mentioned yourself in f-e-c, "the sudden appearance of sqlite > v3 in Rawhide has created chaos", and I'm just trying to help clean it > up. Yes, but in "devel" please. ;) > If it isn't dealt with soon then it will be too late, and anyone that > has kannel or moodss installed will be unable to cleanly upgrade to FC4 > without manual intervention. Maybe taking this topic to maintainers-list or filing bug reports would help? I mean, either the existing sqlite deps can be updated to work with sqlite v3 or they cannot. In case of the latter, an sqlite2 package is what has been suggested some time ago (also in the %prep section of the sqlite package in "devel" when sqlite appeared in Rawhide). > Now, shall I proceed with the creation and import of a sqlite2 package > that obsoletes sqlite < 3? In "devel" that would be the road of least surprise, also with regard to Jean-Luc's need to sqlite tcl, which had appeared in Rawhide and then was removed again, btw. From ivazquez at ivazquez.net Thu Apr 21 10:30:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 06:30:14 -0400 Subject: sqlite update plans (was: Re: APPROVED: sqlite) In-Reply-To: <20050421120523.4dc5d3b4.bugs.michael@gmx.net> References: <1113888761.13656.19.camel@ignacio.ignacio.lan> <20050419114752.74ebed36.bugs.michael@gmx.net> <1113906578.13656.25.camel@ignacio.ignacio.lan> <1114009741.13656.92.camel@ignacio.ignacio.lan> <20050420171931.5be107c5@python2> <20050420183910.11226215.bugs.michael@gmx.net> <1114043139.13656.101.camel@ignacio.ignacio.lan> <20050421120523.4dc5d3b4.bugs.michael@gmx.net> Message-ID: <1114079414.13656.128.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 12:05 +0200, Michael Schwendt wrote: > On Wed, 20 Apr 2005 20:25:39 -0400, Ignacio Vazquez-Abrams wrote: > > > On Wed, 2005-04-20 at 18:39 +0200, Michael Schwendt wrote: > > > On Wed, 20 Apr 2005 17:19:31 +0200, Matthias Saou wrote: > > > > > > > Ignacio Vazquez-Abrams wrote : > > > > > > > > > So after some thinking here then is my plan of attack: > > > > > > > > > > 1) Reimport the sqlite-2.8.16-1 package as sqlite2-2.8.16-1. > > > > > 2) Provide a patch for kannel for it to use sqlite2. > > > > > 3) Reimport the python-sqlite package as python-sqlite2 and have it > > > > > obsolete anything older than or equal to the current python-sqlite > > > > > package. > > > > > 4) Import the python-sqlite package from Rawhide and have the devel > > > > > branch pruned once it's synced for FC3. > > > > > > Re 4) there is a python-sqlite in FC-3 branch already and it's for > > > the v2 sqlite version. > > > > Yes, hence step 3. > > Can we let the FC-3 branch rest in peace until everything is sorted out > in "devel"? That's all I would like to recommend. > > > On Wed, 2005-04-20 at 18:39 +0200, Michael Schwendt wrote: > > > Right. And the question is not silly. I find it natural to develop and > > > prepare for FC4 and only do major version upgrades for FE3 if there is > > > demand [in form of package dependencies]. > > > > As you had mentioned yourself in f-e-c, "the sudden appearance of sqlite > > v3 in Rawhide has created chaos", and I'm just trying to help clean it > > up. > > Yes, but in "devel" please. ;) > > > If it isn't dealt with soon then it will be too late, and anyone that > > has kannel or moodss installed will be unable to cleanly upgrade to FC4 > > without manual intervention. > > Maybe taking this topic to maintainers-list or filing bug reports would > help? I mean, either the existing sqlite deps can be updated to work with > sqlite v3 or they cannot. In case of the latter, an sqlite2 package is > what has been suggested some time ago (also in the %prep section of the > sqlite package in "devel" when sqlite appeared in Rawhide). > > > Now, shall I proceed with the creation and import of a sqlite2 package > > that obsoletes sqlite < 3? > > In "devel" that would be the road of least surprise, also with regard > to Jean-Luc's need to sqlite tcl, which had appeared in Rawhide and then > was removed again, btw. Fair enough, one step at a time works for me. I'll put together a sqlite2 package and submit the spec file for review. Then once it's been imported I'll file bugs against each of the packages affected in order to get the deps changed. -- 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 Thu Apr 21 11:03:30 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 07:03:30 -0400 Subject: Review Needed: sqlite2 Message-ID: <1114081410.13656.131.camel@ignacio.ignacio.lan> Here's the spec file modified from sqlite in Extras to become sqlite2. The sources and patches are the same as found in the existing sqlite-2.8.16-1 SRPM. http://fedora.ivazquez.net/files/sqlite2.spec -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 21 11:12:31 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 21 Apr 2005 13:12:31 +0200 Subject: Review Needed: sqlite2 In-Reply-To: <1114081410.13656.131.camel@ignacio.ignacio.lan> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> Message-ID: <20050421131231.77b5d951@python2> Ignacio Vazquez-Abrams wrote : > Here's the spec file modified from sqlite in Extras to become sqlite2. > The sources and patches are the same as found in the existing > sqlite-2.8.16-1 SRPM. > > http://fedora.ivazquez.net/files/sqlite2.spec Diff'ing it, the few changes seem sane. But at the same time, I realized that the sqlite in FC-3 is still version 3. Will you fix that by changing it back to version 2 and leaving the FC-3 branch alone? I'm also asking because you dropped the epoch again etc. so I guess you based this spec on the FC-2 one and not the previous FC-3 which had already been cleaned up, which is a bit of waisted work. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.29 0.75 0.80 From bugs.michael at gmx.net Thu Apr 21 11:29:07 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 21 Apr 2005 13:29:07 +0200 Subject: Review Needed: sqlite2 In-Reply-To: <20050421131231.77b5d951@python2> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> Message-ID: <20050421132907.209ee3e3.bugs.michael@gmx.net> On Thu, 21 Apr 2005 13:12:31 +0200, Matthias Saou wrote: > Ignacio Vazquez-Abrams wrote : > > > Here's the spec file modified from sqlite in Extras to become sqlite2. > > The sources and patches are the same as found in the existing > > sqlite-2.8.16-1 SRPM. > > > > http://fedora.ivazquez.net/files/sqlite2.spec > > Diff'ing it, the few changes seem sane. > But at the same time, I realized that the sqlite in FC-3 is still version > 3. Will you fix that by changing it back to version 2 and leaving the FC-3 > branch alone? I'm also asking because you dropped the epoch again etc. so > I guess you based this spec on the FC-2 one and not the previous FC-3 > which had already been cleaned up, which is a bit of waisted work. Looks like a diff against FC-3 sqlite-2_8_16-1. The more recent one is cvs co -r sqlite-2_8_16-2 sqlite which should contain Matthias' cleanup changes. Missing "Obsoletes" for the -devel and -tcl sub-packages. From a.kurtz at hardsun.net Thu Apr 21 11:54:59 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 21 Apr 2005 04:54:59 -0700 Subject: Review needed: netspeed_applet Message-ID: <1114084499.6921.17.camel@rydia.hardsun.net> Hi. I would like to submit netspeed_applet for review for inclusion in Extras. SPEC: http://rydia.hardsun.net:8080/netspeed_applet.spec "netspeed_applet is a little GNOME applet that shows the traffic on a specified network device (for example eth0) in kbytes/s." I'm aware that underscores are generally against the naming guidelines, but that's how it's been packaged for Fedora in the past by Dag and the way the developer releases it in tar.gz form. -- Aaron Kurtz From ivazquez at ivazquez.net Thu Apr 21 12:07:22 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 08:07:22 -0400 Subject: Review Needed: sqlite2 In-Reply-To: <20050421132907.209ee3e3.bugs.michael@gmx.net> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> Message-ID: <1114085242.13656.141.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 13:29 +0200, Michael Schwendt wrote: > On Thu, 21 Apr 2005 13:12:31 +0200, Matthias Saou wrote: > > > Ignacio Vazquez-Abrams wrote : > > > > > Here's the spec file modified from sqlite in Extras to become sqlite2. > > > The sources and patches are the same as found in the existing > > > sqlite-2.8.16-1 SRPM. > > > > > > http://fedora.ivazquez.net/files/sqlite2.spec > > > > Diff'ing it, the few changes seem sane. > > But at the same time, I realized that the sqlite in FC-3 is still version > > 3. Will you fix that by changing it back to version 2 and leaving the FC-3 > > branch alone? I am actually going to leave it alone for now. The sqlite2 package obsoletes the sqlite-2.8.16 package, so having the sqlite package remain 2.8.16 is pointless should the sqlite2 package be branched to FC-3, which is what will be required in order to provide a clean upgrade to FC4 re kannel and moodss. But one step at a time. > > I'm also asking because you dropped the epoch again etc. so > > I guess you based this spec on the FC-2 one and not the previous FC-3 > > which had already been cleaned up, which is a bit of waisted work. > > Looks like a diff against FC-3 sqlite-2_8_16-1. The more recent one > is > > cvs co -r sqlite-2_8_16-2 sqlite > > which should contain Matthias' cleanup changes. Yeah, my bad. I have now rediffed it against 2.8.16-2. I did drop the "rebuilt" changelog entry though. > Missing "Obsoletes" for the -devel and -tcl sub-packages. Fixed. -- 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 Thu Apr 21 12:11:05 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 08:11:05 -0400 Subject: Review needed: netspeed_applet In-Reply-To: <1114084499.6921.17.camel@rydia.hardsun.net> References: <1114084499.6921.17.camel@rydia.hardsun.net> Message-ID: <1114085465.13656.144.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 04:54 -0700, Aaron Kurtz wrote: > SPEC: http://rydia.hardsun.net:8080/netspeed_applet.spec > %post > scrollkeeper-update -q -o %{_datadir}/omf/NAME || : Shouldn't that be %{name} at the end there? Also, you don't need the epoch in your changelog entry. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 21 12:20:44 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 21 Apr 2005 14:20:44 +0200 Subject: Review Needed: sqlite2 In-Reply-To: <1114085242.13656.141.camel@ignacio.ignacio.lan> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> <1114085242.13656.141.camel@ignacio.ignacio.lan> Message-ID: <20050421142044.5e65c8c3@python2> Ignacio Vazquez-Abrams wrote : > I am actually going to leave it alone for now. The sqlite2 package > obsoletes the sqlite-2.8.16 package, so having the sqlite package remain > 2.8.16 is pointless should the sqlite2 package be branched to FC-3, > which is what will be required in order to provide a clean upgrade to > FC4 re kannel and moodss. But one step at a time. I still don't understand. Why change anything for FC-3 at all? I really don't see the point, and would prefer avoiding pushing out a new kannel package for FC-3 which has for only change a build requirement of "sqlite2- devel" instead of "sqlite-devel"... My preference would be to undo the sqlite v2 to v3 change in the FC-3 branch, remove sqlite from the devel branch (as sqlite v3 is in Core) and import the FC-3 sqlite v2 as "sqlite2" in the devel branch with those last changes you suggested. >From there, we can fix and rebuild all packages in devel that rely on either version of sqlite, and make sure we provide a working upgrade path from FC3 to FC4 for end users. Why do you want to go and introduce major changes to the FC-3 branch? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.64 0.90 0.65 From dwmw2 at infradead.org Thu Apr 21 12:49:20 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Apr 2005 22:49:20 +1000 Subject: ulog not on ppc? In-Reply-To: <42669BA1.3070507@redhat.com> References: <1114003722.5877.28.camel@localhost.localdomain> <42669BA1.3070507@redhat.com> Message-ID: <1114087762.29135.28.camel@localhost.localdomain> On Wed, 2005-04-20 at 08:12 -1000, Warren Togami wrote: > Until we have a feasible way of giving arch login accounts for testing > purposes to anybody, we cannot possibly expect blocking on archs. > Unless you want dozens of bugs filed "not built on x86_64 and ppc > because it is untested"? I wouldn't suggest that we refrain from building a package on a given architecture merely because it's untested. I'm suggesting that if there are known reasons for _not_ building on a given arch, there must be a bug filed. -- dwmw2 From dwmw2 at infradead.org Thu Apr 21 12:50:41 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Apr 2005 22:50:41 +1000 Subject: ulog not on ppc? In-Reply-To: <20050420161110.241c5ebb.bugs.michael@gmx.net> References: <1114003722.5877.28.camel@localhost.localdomain> <1114004020.15629.57.camel@cutter> <1114005803.5877.33.camel@localhost.localdomain> <20050420161110.241c5ebb.bugs.michael@gmx.net> Message-ID: <1114087842.29135.30.camel@localhost.localdomain> On Wed, 2005-04-20 at 16:11 +0200, Michael Schwendt wrote: > > Perhaps -- but since most packagers don't specify an arch to build when > > it's to be built for all arches, I figured it was best to ask rather > > than just change it. > > That's misinterpretation. So far, most packagers have had to > specify "(i386, x86_64)" explicitly. It's a recent change that no arch > in brackets means to build for all archs. Ah, OK. I hadn't been paying much attention to the wiki because I've just been doing my own builds for FC3 before now. Upon looking, I saw it documented that you should only list architectures if you wanted to limit the build, and there was only one package which did so... -- dwmw2 From djh at iinet.net.au Thu Apr 21 14:45:35 2005 From: djh at iinet.net.au (djh) Date: Fri, 22 Apr 2005 00:45:35 +1000 Subject: Review Needed: sqlite2 In-Reply-To: <20050421142044.5e65c8c3@python2> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> <1114085242.13656.141.camel@ignacio.ignacio.lan> <20050421142044.5e65c8c3@python2> Message-ID: <4267BC8F.5090601@iinet.net.au> Matthias Saou wrote: >I still don't understand. Why change anything for FC-3 at all? > > Why not just revert the package renaming (sqlite3 to sqlite) that caused these problems? David. From mattdm at mattdm.org Thu Apr 21 15:45:00 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 21 Apr 2005 11:45:00 -0400 Subject: Review Needed: sqlite2 In-Reply-To: <4267BC8F.5090601@iinet.net.au> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> <1114085242.13656.141.camel@ignacio.ignacio.lan> <20050421142044.5e65c8c3@python2> <4267BC8F.5090601@iinet.net.au> Message-ID: <20050421154500.GA28147@jadzia.bu.edu> On Fri, Apr 22, 2005 at 12:45:35AM +1000, djh wrote: > Why not just revert the package renaming (sqlite3 to sqlite) that caused > these problems? Because it's the normal standard for the current version of a package to not have a number smashed into its name. And there *is* a perfectly good way to make that work just fine. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From tcallawa at redhat.com Thu Apr 21 15:53:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 21 Apr 2005 10:53:01 -0500 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK In-Reply-To: <1113936616.19436.102.camel@swoop> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> <1113936616.19436.102.camel@swoop> Message-ID: <1114098781.3297.54.camel@localhost.localdomain> On Tue, 2005-04-19 at 13:50 -0500, Tom 'spot' Callaway wrote: > Updated packages: > > blacs: > SRPM:http://www.auroralinux.org/people/spot/R/blacs-1.1-4.src.rpm > SPEC:http://www.auroralinux.org/people/spot/R/blacs.spec > > scalapack: > SRPM:http://www.auroralinux.org/people/spot/R/scalapack-1.7-2.src.rpm > SPEC:http://www.auroralinux.org/people/spot/R/scalapack.spec > > R-RScaLAPACK: > SRPM:http://www.auroralinux.org/people/spot/R/R-RScaLAPACK-0.4.0-2.src.rpm > SPEC:http://www.auroralinux.org/people/spot/R/R-RScaLAPACK.spec Ed, Would you (or another supporter of Math related packages) care to take another review at this? I've got a lot of R-* packages waiting, I'd like to get as many of them in before fc4 as possible. Unless of course, you think they're ok as is, and if so, just let me know. :) Thanks, ~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 rc040203 at freenet.de Thu Apr 21 16:08:45 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Apr 2005 18:08:45 +0200 Subject: Review Needed: sqlite2 In-Reply-To: <20050421154500.GA28147@jadzia.bu.edu> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> <1114085242.13656.141.camel@ignacio.ignacio.lan> <20050421142044.5e65c8c3@python2> <4267BC8F.5090601@iinet.net.au> <20050421154500.GA28147@jadzia.bu.edu> Message-ID: <1114099725.26656.11.camel@mccallum.corsepiu.local> On Thu, 2005-04-21 at 11:45 -0400, Matthew Miller wrote: > On Fri, Apr 22, 2005 at 12:45:35AM +1000, djh wrote: > > Why not just revert the package renaming (sqlite3 to sqlite) that caused > > these problems? > > Because it's the normal standard for the current version of a package to > not have a number smashed into its name. iif the package is 100% backward compatible or if the new package and all packages depending on it are replaced at once. If this doesn't hold, the most simple way to work around potential upgrading and compatibility issues is to leave the old package as it is and to use a different name for the new one. A less simple way would be to re-package the old package into "compat- packages". Renaming an already released package and continue to use the old name for a new, incompatible package means asking for trouble. Ralf From qspencer at ieee.org Thu Apr 21 16:32:28 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 21 Apr 2005 11:32:28 -0500 Subject: Review Request: fftw3 cln GiNaC octave-forge In-Reply-To: <1114098781.3297.54.camel@localhost.localdomain> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> <1113936616.19436.102.camel@swoop> <1114098781.3297.54.camel@localhost.localdomain> Message-ID: <4267D59C.2000804@ieee.org> I have recently imported these functions into CVS. Octave-forge is a set of add-on functions for octave, and the others are all math libraries. Note that octave-forge depends on GiNaC, which depends on cln. From Jochen at herr-schmitt.de Thu Apr 21 16:40:33 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 21 Apr 2005 18:40:33 +0200 Subject: Fedora Extras: Get involved more easily! In-Reply-To: References: Message-ID: <0ML29c-1DOejC0qV8-0008UW@mrelayeu.kundenserver.de> On Mon, 18 Apr 2005 16:54:05 -0400 (EDT), you wrote: >If you'd like to become a Fedora Extras developer, but the process of >getting CVS access seemed too slow before, please visit >https://admin.fedora.redhat.com/accounts/ to use the new automated system. Hello, I have create a account with the name 's4504kr' in the new admin system and completed the ICLA proecess. Unfortunately, My sponsor didn't know, what he has to do on this new admin system. So it will be nice, if you can explain us, what we have to do. Best Regards: Jochen Schmitt From ivazquez at ivazquez.net Thu Apr 21 17:01:46 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 13:01:46 -0400 Subject: Review Needed: sqlite2 In-Reply-To: <20050421142044.5e65c8c3@python2> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> <1114085242.13656.141.camel@ignacio.ignacio.lan> <20050421142044.5e65c8c3@python2> Message-ID: <1114102906.13656.146.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 14:20 +0200, Matthias Saou wrote: > Ignacio Vazquez-Abrams wrote : > > > I am actually going to leave it alone for now. The sqlite2 package > > obsoletes the sqlite-2.8.16 package, so having the sqlite package remain > > 2.8.16 is pointless should the sqlite2 package be branched to FC-3, > > which is what will be required in order to provide a clean upgrade to > > FC4 re kannel and moodss. But one step at a time. > > I still don't understand. Why change anything for FC-3 at all? I really > don't see the point, and would prefer avoiding pushing out a new kannel > package for FC-3 which has for only change a build requirement of "sqlite2- > devel" instead of "sqlite-devel"... > > My preference would be to undo the sqlite v2 to v3 change in the FC-3 > branch, remove sqlite from the devel branch (as sqlite v3 is in Core) and > import the FC-3 sqlite v2 as "sqlite2" in the devel branch with those last > changes you suggested. > > >From there, we can fix and rebuild all packages in devel that rely on > either version of sqlite, and make sure we provide a working upgrade path > from FC3 to FC4 for end users. > > Why do you want to go and introduce major changes to the FC-3 branch? The problem goes beyond just kannel and moodss. What about yum? Can yum in Rawhide work equally well with sqlite 2.8 as well as 3? -- 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 Fri Apr 22 05:47:48 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 22 Apr 2005 01:47:48 -0400 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK In-Reply-To: <1114098781.3297.54.camel@localhost.localdomain> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> <1113936616.19436.102.camel@swoop> <1114098781.3297.54.camel@localhost.localdomain> Message-ID: <1114148868.27414.14.camel@ernie> On Thu, 2005-04-21 at 10:53 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-04-19 at 13:50 -0500, Tom 'spot' Callaway wrote: > > > Updated packages: > > > > blacs: > > SRPM:http://www.auroralinux.org/people/spot/R/blacs-1.1-4.src.rpm > > SPEC:http://www.auroralinux.org/people/spot/R/blacs.spec > > > > scalapack: > > SRPM:http://www.auroralinux.org/people/spot/R/scalapack-1.7-2.src.rpm > > SPEC:http://www.auroralinux.org/people/spot/R/scalapack.spec > > > > R-RScaLAPACK: > > SRPM:http://www.auroralinux.org/people/spot/R/R-RScaLAPACK-0.4.0-2.src.rpm > > SPEC:http://www.auroralinux.org/people/spot/R/R-RScaLAPACK.spec > > Ed, > > Would you (or another supporter of Math related packages) care to take > another review at this? I've got a lot of R-* packages waiting, I'd like > to get as many of them in before fc4 as possible. Hi Tom, The blacs and scalapack RPMs look fine to me. They built, installed, un-installed, etc. cleanly on a box thats running FC3 plus all the "yum update"-s from the devel repo. I also tried R-RScaLAPACK and had some annoying issue wrt gcc-g77 dependencies and it has nothing to do with R-RScaLAPACK itself. I need to build a fresh FC4-test box anyway (for other reasons) so I'll try R- RScaLAPACK again over the weekend. 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 perbj at stanford.edu Thu Apr 21 17:40:29 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 21 Apr 2005 10:40:29 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <1114084499.6921.17.camel@rydia.hardsun.net> References: <1114084499.6921.17.camel@rydia.hardsun.net> Message-ID: <1114105229.4738.12.camel@localhost.localdomain> On Thu, 2005-04-21 at 04:54 -0700, Aaron Kurtz wrote: > Hi. > I would like to submit netspeed_applet for review for inclusion in > Extras. ... > I'm aware that underscores are generally against the naming guidelines, > but that's how it's been packaged for Fedora in the past by Dag and the > way the developer releases it in tar.gz form. Well, it's also a Gnome panel applet, and according to the package naming guidelines it seems to me that the should be named gnome-applet- netspeed in that case. (It's useful that the package clearly denotes that it's a Gnome applet as opposed to say a KDE add-on of some sort. Also, you can easily find Gnome applets by doing a "yum list gnome- applet-\*' when this naming convention is used.) Regarding the earlier packages, it's certainly possible to pull the obsoletes/provides trick to provide a sane upgrade path: http://www.fedoraproject.org/wiki/PackageNamingGuidelines#head-2c81f7aaf6772e9816f9cf8c5eb62efac828e902 (The sections on renaming and "add-on packages" are conveniently located right next to each other here.) Of course, this change would necessitate some minor changes in the spec , where you use %{name}. Otherwise, apart from what Ignacio commented on, I think this looks good. /Per From wtogami at redhat.com Thu Apr 21 20:24:31 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Apr 2005 10:24:31 -1000 Subject: Review Request: fftw3 cln GiNaC octave-forge In-Reply-To: <4267D59C.2000804@ieee.org> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> <1113936616.19436.102.camel@swoop> <1114098781.3297.54.camel@localhost.localdomain> <4267D59C.2000804@ieee.org> Message-ID: <42680BFF.1010506@redhat.com> Quentin Spencer wrote: > I have recently imported these functions into CVS. Octave-forge is a set > of add-on functions for octave, and the others are all math libraries. > Note that octave-forge depends on GiNaC, which depends on cln. THIS IS NOT A REVIEW, only preliminary observations. I didn't attempt to build it. octave-forge ============ ## Octave-forge installs in a directory tree specific to the installed ## version of octave, so the following version dependency is necessary. %define octave_ep %(rpm -q --qf '%%{epoch}' octave) %define octave_ver %(rpm -q --qf '%%{version}' octave) Requires: octave = %{octave_ep}:%{octave_ver} ImageMagick You must not query rpmdb during rpmbuild. This also causes ugly messages when parsing the spec when octave is not installed. Please just hard-code it. GiNaC ===== BuildRequires: cln-devel >= 1.1 gcc-c++ No need to ever list gcc or gcc-c++. Just assume it is in the buildroot. %package devel Summary: GiNaC development libraries and header files Group: Development/Libraries Requires: %{name} = %{version} Make it %{version}-%{release} in each subpackage. (in cln too) It appears that RPM_OPT_FLAGS aren't being passed to the build flags. cln === Again RPM_OPT_FLAGS Warren Togami wtogami at redhat.com From jdennis at redhat.com Thu Apr 21 20:57:43 2005 From: jdennis at redhat.com (John Dennis) Date: Thu, 21 Apr 2005 16:57:43 -0400 Subject: can I get an approval for cyrus-imapd? Message-ID: <1114117063.18527.19.camel@localhost.localdomain> I'd like to progress cyrus-imap into the APPROVED state and get it built. So far there have been two reviewers with comments: Enrico Scholz Ignacio Vazquez-Abrams I believe the substance of the comments have been addressed. Enrico want the SSL certificate location moved from /usr/share/ssl/certs and that has been done (we finally came to an agreement on a "standard" location for certs, /etc/pki, with a subdirectory for each application/package where they put their own certs). The rpm was modified to use /etc/pki/cyrus-imapd for its certificate obsolescing the previous proposal of /etc/cyrus-imapd. Ignacio noted the license was BSD (or a close variant), the license field was updated to reflect this. Ignacio also noted that summaries should end with a period. I would prefer not to delete the periods in each of the summaries because it introduces differences with the spec file it is based on (Simon Matter's) without significant benefit. Those are the only comments so far. I have built, installed, and tested the latest version of the rpm (locally). The changes are all in extras CVS if folks want another go at reviewing, otherwise can we move this into an APPROVED state? -- John Dennis From wtogami at redhat.com Thu Apr 21 21:01:31 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Apr 2005 11:01:31 -1000 Subject: can I get an approval for cyrus-imapd? In-Reply-To: <1114117063.18527.19.camel@localhost.localdomain> References: <1114117063.18527.19.camel@localhost.localdomain> Message-ID: <426814AB.6090908@redhat.com> Just go ahead for FC4, it is rawhide-like anyway and it can be rebuilt again if it is broken. I am happy that a new standard outside of /usr was chosen for keys. Thanks to everyone for attention to detail. Please do the APPROVED post to fedora-extras-commits. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Apr 21 21:05:32 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Apr 2005 11:05:32 -1000 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK In-Reply-To: <1114148868.27414.14.camel@ernie> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> <1113936616.19436.102.camel@swoop> <1114098781.3297.54.camel@localhost.localdomain> <1114148868.27414.14.camel@ernie> Message-ID: <4268159C.3020901@redhat.com> Hi Ed, could you please correct your system clock and/or timezone? You appear to be posting from 8+ hours in the future. Thanks, Warren Togami wtogami at redhat.com p.s. Please package your time machine, if it isn't encumbered by software patents. Or go back in time and patent it yourself. Oh and please patent MPEG and MP3 while you're there. From msmart890 at access-4-free.com Thu Apr 21 21:21:08 2005 From: msmart890 at access-4-free.com (msmart890 at access-4-free.com) Date: Thu, 21 Apr 2005 16:21:08 -0500 Subject: removal from list Message-ID: <42681944.2ae.578.24575@access-4-free.com> please remove me from this list From a.kurtz at hardsun.net Thu Apr 21 21:19:06 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 21 Apr 2005 14:19:06 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <1114105229.4738.12.camel@localhost.localdomain> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> Message-ID: <1114118346.6921.24.camel@rydia.hardsun.net> On Thu, 2005-04-21 at 10:40 -0700, Per Bjornsson wrote: > On Thu, 2005-04-21 at 04:54 -0700, Aaron Kurtz wrote: > > Hi. > > I would like to submit netspeed_applet for review for inclusion in > > Extras. > ... > > I'm aware that underscores are generally against the naming guidelines, > > but that's how it's been packaged for Fedora in the past by Dag and the > > way the developer releases it in tar.gz form. > > Of course, this change would necessitate some minor changes in the > spec , where you use %{name}. Otherwise, apart from what Ignacio > commented on, I think this looks good. Renamed, obsolete/provides added, and Ignacio's points fixed. The new spec is at: http://rydia.hardsun.net:8080/gnome-applet-netspeed.spec -- Aaron Kurtz References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> <87mzrufou4.fsf@kosh.bigo.ensc.de> Message-ID: <1114118894.4489.11.camel@fc4t2.mpeters.local> On Tue, 2005-04-19 at 23:17 +0200, Enrico Scholz wrote: > jeff at ocjtech.us ("Jeffrey C. Ollie") writes: > > >> Hmmm... Having a problem with the CLA process. First of all, the system > >> does not appear to handle GPG-signed email messages. > > ... > > Well, I think that I solved my problem. It seems that the automated > > system has problems with GPG keys that have multiple IDs. > > Which keyserver is used by the system? Fedora doc refers to pgp.mit.edu > which should not be used nowadays anymore as it can does not work with > subkeys. A modern SKS keyserver like 'sks.keyserver.penguin.de' should > be used instead of. I have the same problem. My key was originally generated with an e-mail address I seldom use (but still own, only access through webmail) Can the docs be updated to detail this scenario and what to do about it? I assume I will have to submit my key to a different keyserver? The keyserver I am with now happens to be the one Fedora Extras documents speak of, but if it doesn't work, then should the docs refer to one that does? my key was originally attached to buildmaster at mpeters.us for a small yum repository I maintain. I then added mpeters at mac.com which is the address I primarily use for e-mail. The message I got back from Fedora - With regards to "Re: Fedora Individual Contributor License Agreement". Your message could not be processed. Reason The signature's key ID did not match the key ID on file. Is there a bugzilla for this? From mpeters at mac.com Thu Apr 21 21:38:36 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 21 Apr 2005 14:38:36 -0700 Subject: Fedora Extras: Get involved more easily! In-Reply-To: <1113946262.27689.52.camel@lt16586.campus.dmacc.edu> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> <1113946262.27689.52.camel@lt16586.campus.dmacc.edu> Message-ID: <1114119516.4489.13.camel@fc4t2.mpeters.local> On Tue, 2005-04-19 at 16:31 -0500, Jeffrey C. Ollie wrote: > > It may have something to do with the order of the IDs on your GPG key. > In my case, I listed an email address on the web page that is listed > second on my GPG key. ditto for me. From perbj at stanford.edu Thu Apr 21 22:03:21 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 21 Apr 2005 15:03:21 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <1114118346.6921.24.camel@rydia.hardsun.net> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> Message-ID: <1114121002.4738.32.camel@localhost.localdomain> On Thu, 2005-04-21 at 14:19 -0700, Aaron Kurtz wrote: > Renamed, obsolete/provides added, and Ignacio's points fixed. The new > spec is at: > > http://rydia.hardsun.net:8080/gnome-applet-netspeed.spec Spec looks fine to me now, and it builds/installs/uninstalls cleanly as far as I can tell here (not rebuilt in a clean build root though, I don't have one accessible right now; this is on FC3). Possibly something for upstream: It didn't seem to detect that my Atheros wireless card was wireless, it just showed a normal ethernet card icon (I think it's supposed to be some kind of squiggle?) Traffic measurement worked fine though. This should certainly not be a blocker for putting it in Extras. /Per From toshio at tiki-lounge.com Thu Apr 21 22:03:30 2005 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 21 Apr 2005 18:03:30 -0400 Subject: Request for review (again?): quilt In-Reply-To: <1114043780.11041.12.camel@jdub.homelinux.org> References: <1114043780.11041.12.camel@jdub.homelinux.org> Message-ID: <1114121013.17056.6.camel@Madison.badger.com> cd /med On Wed, 2005-04-20 at 19:36 -0500, Josh Boyer wrote: > Hi, > > I've imported the quilt package into CVS now. It's already gone through > a review from a couple of folks a while back, but I thought I would post > another review just to be sure I followed the process. > Things look pretty good. The imported sources closely mirror what was reviewed. One question, though -- why was the Requires: rpm-build removed? Was it because `quilt setup` functionality wasn't deemed necessary or because rpm-build is always supposed to be installed? -Toshio -- toshio \ Questions for the Would Morticia wear it? @tiki- \ 21st Century! Would it look better on me? lounge.com=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ GA->ME 1999 -------------- 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 Apr 21 17:34:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 21 Apr 2005 13:34:58 -0400 Subject: Review Needed: sqlite2 In-Reply-To: <1114099725.26656.11.camel@mccallum.corsepiu.local> References: <1114081410.13656.131.camel@ignacio.ignacio.lan> <20050421131231.77b5d951@python2> <20050421132907.209ee3e3.bugs.michael@gmx.net> <1114085242.13656.141.camel@ignacio.ignacio.lan> <20050421142044.5e65c8c3@python2> <4267BC8F.5090601@iinet.net.au> <20050421154500.GA28147@jadzia.bu.edu> <1114099725.26656.11.camel@mccallum.corsepiu.local> Message-ID: <1114104898.23497.36.camel@cutter> On Thu, 2005-04-21 at 18:08 +0200, Ralf Corsepius wrote: > On Thu, 2005-04-21 at 11:45 -0400, Matthew Miller wrote: > > On Fri, Apr 22, 2005 at 12:45:35AM +1000, djh wrote: > > > Why not just revert the package renaming (sqlite3 to sqlite) that caused > > > these problems? > > > > Because it's the normal standard for the current version of a package to > > not have a number smashed into its name. > > iif the package is 100% backward compatible or if the new package and > all packages depending on it are replaced at once. > > If this doesn't hold, the most simple way to work around potential > upgrading and compatibility issues is to leave the old package as it is > and to use a different name for the new one. > > A less simple way would be to re-package the old package into "compat- > packages". > > Renaming an already released package and continue to use the old name > for a new, incompatible package means asking for trouble. > you mean like glibc does all the time? come on - fedora repeatedly brings in new, api/abi incompatible library updates as the same package name. The old one gets renamed, no the new one. -sv From jwboyer at jdub.homelinux.org Thu Apr 21 23:14:04 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Apr 2005 18:14:04 -0500 Subject: Request for review (again?): quilt In-Reply-To: <1114121013.17056.6.camel@Madison.badger.com> References: <1114043780.11041.12.camel@jdub.homelinux.org> <1114121013.17056.6.camel@Madison.badger.com> Message-ID: <1114125244.11041.22.camel@jdub.homelinux.org> On Thu, 2005-04-21 at 18:03 -0400, Toshio wrote: > cd /med On Wed, 2005-04-20 at 19:36 -0500, Josh Boyer wrote: > > Hi, > > > > I've imported the quilt package into CVS now. It's already gone through > > a review from a couple of folks a while back, but I thought I would post > > another review just to be sure I followed the process. > > > Things look pretty good. The imported sources closely mirror what was > reviewed. One question, though -- why was the Requires: rpm-build > removed? Was it because `quilt setup` functionality wasn't deemed > necessary or because rpm-build is always supposed to be installed? The latter. I can add it back in and get rid of some of the other Requires: that it depends on if you'd like. That does make sense. Ok, I've made that change and checked it into CVS. Any other comments from anyone? thx, josh From ed at eh3.com Fri Apr 22 00:46:05 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 21 Apr 2005 20:46:05 -0400 Subject: Request for Review: blacs, scalapack, R-RScaLAPACK In-Reply-To: <4268159C.3020901@redhat.com> References: <1113921269.19436.74.camel@swoop> <1113931088.19567.17.camel@ernie> <1113936616.19436.102.camel@swoop> <1114098781.3297.54.camel@localhost.localdomain> <1114148868.27414.14.camel@ernie> <4268159C.3020901@redhat.com> Message-ID: <1114130766.27414.88.camel@ernie> On Thu, 2005-04-21 at 11:05 -1000, Warren Togami wrote: > Hi Ed, could you please correct your system clock and/or timezone? You > appear to be posting from 8+ hours in the future. OK, its fixed for now. Sorry. > p.s. Please package your time machine, if it isn't encumbered by > software patents. Or go back in time and patent it yourself. Oh and > please patent MPEG and MP3 while you're there. Ha! Don't we all wish! ;-) And since you brought up the topic it is, in some sense, already packaged. Its called: kernel-2.6.10-1.770_FC3 + ThinkPad T42p + use of ACPI S3 and the above combo produces strange times every time I do a suspend and resume cycle. The problem is fixed in kernel-2.6.11-1.14_FC3 but that kernel seems to cause occasional complete lock-ups that leave absolutely no trace in /var/log/messages. And yes, I know that these things should get added to bugzilla. I'm just utterly perplexed as to what I ought to put in a bugzilla entry describing the lockups. I'm hoping that some pattern will emerge so that I can make some guesses as to whats triggering it. 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 Fri Apr 22 04:22:35 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 22 Apr 2005 06:22:35 +0200 Subject: GPG signature issue (was Re: Fedora Extras: Get involved more easily!) In-Reply-To: <1114118894.4489.11.camel@fc4t2.mpeters.local> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> <87mzrufou4.fsf@kosh.bigo.ensc.de> <1114118894.4489.11.camel@fc4t2.mpeters.local> Message-ID: <1114143755.26656.40.camel@mccallum.corsepiu.local> On Thu, 2005-04-21 at 14:28 -0700, Michael A. Peters wrote: > The message I got back from Fedora - > > With regards to "Re: Fedora Individual Contributor License Agreement". > Your message could not be processed. > Reason The signature's key ID did not match the key ID on file. Check the spelling of the key-ID you inserted into the web-form against that one gpg reported being used on your "*.txt.asc". I managed to complete the procedure, after having changed my key-ID in the form from a "lower-cased" to an "upper-cased" hex number and then "requesting and signing" the CLA once again. Ralf From ivazquez at ivazquez.net Fri Apr 22 05:42:37 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 22 Apr 2005 01:42:37 -0400 Subject: Wiki page for packages? Message-ID: <1114148557.7784.3.camel@ignacio.ignacio.lan> There seem to be a lot of packages out there that need sponsors or review, and it's getting tedious to hunt down in the mailing list which packages have been sponsored/reviewed and which haven't. How about having a wiki page where we can track what packages still need to be dealt with? Requests will still have to be sent to the list, but the packager would also add the package to the page. -- 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 wtogami at redhat.com Fri Apr 22 05:42:50 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 21 Apr 2005 19:42:50 -1000 Subject: Wiki page for packages? In-Reply-To: <1114148557.7784.3.camel@ignacio.ignacio.lan> References: <1114148557.7784.3.camel@ignacio.ignacio.lan> Message-ID: <42688EDA.3080904@redhat.com> Ignacio Vazquez-Abrams wrote: > There seem to be a lot of packages out there that need sponsors or > review, and it's getting tedious to hunt down in the mailing list which > packages have been sponsored/reviewed and which haven't. How about > having a wiki page where we can track what packages still need to be > dealt with? Requests will still have to be sent to the list, but the > packager would also add the package to the page. Not another Wiki page... We're aiming to replace the current process with a simplified Bugzilla process that I'm designing with dkl. Everyone agrees that the current process is a horrible mess, and Wiki is a large part of the reason for the current mess. Wiki is great for documentation management, but terrible when it comes to workflow management. Warren Togami wtogami at redhat.com From mpeters at mac.com Fri Apr 22 06:27:38 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 21 Apr 2005 23:27:38 -0700 Subject: GPG signature issue (was Re: Fedora Extras: Get involved more easily!) In-Reply-To: <1114143755.26656.40.camel@mccallum.corsepiu.local> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> <87mzrufou4.fsf@kosh.bigo.ensc.de> <1114118894.4489.11.camel@fc4t2.mpeters.local> <1114143755.26656.40.camel@mccallum.corsepiu.local> Message-ID: <1114151258.4489.19.camel@fc4t2.mpeters.local> On Fri, 2005-04-22 at 06:22 +0200, Ralf Corsepius wrote: > > I managed to complete the procedure, after having changed my key-ID in > the form from a "lower-cased" to an "upper-cased" hex number and then > "requesting and signing" the CLA once again. I tried that - still nogo. I'm tempted to just open up another e-mail address and start with a fresh key just for that address, and see if that does things better. Hopefully there won't be an issue with me changing the e-mail address on file. I'll try again tomorrow. From mpeters at mac.com Fri Apr 22 06:32:23 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 21 Apr 2005 23:32:23 -0700 Subject: Wiki page for packages? In-Reply-To: <42688EDA.3080904@redhat.com> References: <1114148557.7784.3.camel@ignacio.ignacio.lan> <42688EDA.3080904@redhat.com> Message-ID: <1114151543.4489.24.camel@fc4t2.mpeters.local> On Thu, 2005-04-21 at 19:42 -1000, Warren Togami wrote: > > Wiki is great for documentation management, but terrible when it comes > to workflow management. I agree. Once I figured the wiki thing out its great for finding stuff - I like it. I can't comment on how good it is for workflow, but I'm betting something with a tracker like bugzilla would be better - problem with e-mail that I'm having is sometimes the replies show up as new threads instead of replies to the request thread, I guess that depends upon the client responding. With a bugzilla (or something similar) it's independent of mail client issues. From mpeters at mac.com Fri Apr 22 07:39:47 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 22 Apr 2005 00:39:47 -0700 Subject: GPG signature issue (was Re: Fedora Extras: Get involved more easily!) In-Reply-To: <1114151258.4489.19.camel@fc4t2.mpeters.local> References: <1113864056.27689.21.camel@lt16586.campus.dmacc.edu> <1113940690.27689.48.camel@lt16586.campus.dmacc.edu> <87mzrufou4.fsf@kosh.bigo.ensc.de> <1114118894.4489.11.camel@fc4t2.mpeters.local> <1114143755.26656.40.camel@mccallum.corsepiu.local> <1114151258.4489.19.camel@fc4t2.mpeters.local> Message-ID: <1114155587.4489.32.camel@fc4t2.mpeters.local> On Thu, 2005-04-21 at 23:27 -0700, Michael A. Peters wrote: > On Fri, 2005-04-22 at 06:22 +0200, Ralf Corsepius wrote: > > > > > I managed to complete the procedure, after having changed my key-ID in > > the form from a "lower-cased" to an "upper-cased" hex number and then > > "requesting and signing" the CLA once again. It's figured out. Entering the ID for the address I was sending from did not work - entering the first ID for the key did. Type bits /keyID Date User ID pub 1024D/02812C3F 2004/11/15 Michael A. Peters (buildmaster) Michael A. Peters (general) pub 1024D/B1491554 2004/04/03 Michael A. Peters Using 02812C3F did the trick - despite the fact that the e-mail info I have with the account is mpeters at mac.com From bugs.michael at gmx.net Fri Apr 22 09:17:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Apr 2005 11:17:22 +0200 Subject: Wiki page for packages? In-Reply-To: <1114151543.4489.24.camel@fc4t2.mpeters.local> References: <1114148557.7784.3.camel@ignacio.ignacio.lan> <42688EDA.3080904@redhat.com> <1114151543.4489.24.camel@fc4t2.mpeters.local> Message-ID: <20050422111722.2a065d16.bugs.michael@gmx.net> On Thu, 21 Apr 2005 23:32:23 -0700, Michael A. Peters wrote: > On Thu, 2005-04-21 at 19:42 -1000, Warren Togami wrote: > > > > > Wiki is great for documentation management, but terrible when it comes > > to workflow management. > > I agree. Once I figured the wiki thing out its great for finding stuff - > I like it. I can't comment on how good it is for workflow, but I'm > betting something with a tracker like bugzilla would be better - problem > with e-mail that I'm having is sometimes the replies show up as new > threads instead of replies to the request thread, I guess that depends > upon the client responding. > > With a bugzilla (or something similar) it's independent of mail client > issues. Current major problem with the Wiki is that one needs to skim over the "RecentChanges" page regularly in order to learn what details have changed. The RSS news feed only displays the title of changed pages and doesn't contain a diff. Not even the summary of changes is included everytime it seems. Without additional converage on mailing-lists, changes to guidelines, policies, or processes remain unknown until somebody runs into them. That's not good. From bugs.michael at gmx.net Fri Apr 22 09:21:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Apr 2005 11:21:55 +0200 Subject: Wiki page for packages? In-Reply-To: <20050422111722.2a065d16.bugs.michael@gmx.net> References: <1114148557.7784.3.camel@ignacio.ignacio.lan> <42688EDA.3080904@redhat.com> <1114151543.4489.24.camel@fc4t2.mpeters.local> <20050422111722.2a065d16.bugs.michael@gmx.net> Message-ID: <20050422112155.5e1805f7.bugs.michael@gmx.net> On Fri, 22 Apr 2005 11:17:22 +0200, Michael Schwendt wrote: > Current major problem with the Wiki is that one needs to skim over the > "RecentChanges" page regularly in order to learn what details have > changed. The RSS news feed only displays the title of changed pages and > doesn't contain a diff. Not even the summary of changes is included > everytime it seems. > > Without additional converage on mailing-lists, changes to guidelines, s/converage/coverage/ > policies, or processes remain unknown until somebody runs into them. > That's not good. From toshio at tiki-lounge.com Fri Apr 22 11:02:50 2005 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 22 Apr 2005 07:02:50 -0400 Subject: Request for review (again?): quilt In-Reply-To: <1114125244.11041.22.camel@jdub.homelinux.org> References: <1114043780.11041.12.camel@jdub.homelinux.org> <1114121013.17056.6.camel@Madison.badger.com> <1114125244.11041.22.camel@jdub.homelinux.org> Message-ID: <1114167774.22400.10.camel@Madison.badger.com> On Thu, 2005-04-21 at 18:14 -0500, Josh Boyer wrote: > On Thu, 2005-04-21 at 18:03 -0400, Toshio wrote: > > On Wed, 2005-04-20 at 19:36 -0500, Josh Boyer wrote: > > > Hi, > > > > > > I've imported the quilt package into CVS now. It's already gone through > > > a review from a couple of folks a while back, but I thought I would post > > > another review just to be sure I followed the process. > > > > > Things look pretty good. The imported sources closely mirror what was > > reviewed. One question, though -- why was the Requires: rpm-build > > removed? Was it because `quilt setup` functionality wasn't deemed > > necessary or because rpm-build is always supposed to be installed? > > The latter. I can add it back in and get rid of some of the other > Requires: that it depends on if you'd like. That does make sense. > > Ok, I've made that change and checked it into CVS. Any other comments > from anyone? Changes look good. If you don't have someone else to sponsor the package, feel free to use me when you post APPROVED. c87dcbd4db3f2183fe3cd76aa25eafd4 fix-man-page.patch 2e069d3e4741fa3e07e9593792e8a92c quilt.spec 34f0c654aefba0342db6c676988634b5 quilt-0.39.tar.gz * Upstream source matches. * Upstream source is signed: key ID E145F334 "Martin Quinson " * Builds in mach * Installs, upgrades, and runs on i386. -Toshio -- _________________ Attraction's easy; love is hard ______________________ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 jwboyer at jdub.homelinux.org Fri Apr 22 11:16:19 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 22 Apr 2005 06:16:19 -0500 Subject: Request for review (again?): quilt In-Reply-To: <1114167774.22400.10.camel@Madison.badger.com> References: <1114043780.11041.12.camel@jdub.homelinux.org> <1114121013.17056.6.camel@Madison.badger.com> <1114125244.11041.22.camel@jdub.homelinux.org> <1114167774.22400.10.camel@Madison.badger.com> Message-ID: <1114168579.11041.46.camel@jdub.homelinux.org> On Fri, 2005-04-22 at 07:02 -0400, Toshio wrote: > On Thu, 2005-04-21 at 18:14 -0500, Josh Boyer wrote: > > On Thu, 2005-04-21 at 18:03 -0400, Toshio wrote: > > > On Wed, 2005-04-20 at 19:36 -0500, Josh Boyer wrote: > > > > Hi, > > > > > > > > I've imported the quilt package into CVS now. It's already gone through > > > > a review from a couple of folks a while back, but I thought I would post > > > > another review just to be sure I followed the process. > > > > > > > Things look pretty good. The imported sources closely mirror what was > > > reviewed. One question, though -- why was the Requires: rpm-build > > > removed? Was it because `quilt setup` functionality wasn't deemed > > > necessary or because rpm-build is always supposed to be installed? > > > > The latter. I can add it back in and get rid of some of the other > > Requires: that it depends on if you'd like. That does make sense. > > > > Ok, I've made that change and checked it into CVS. Any other comments > > from anyone? > > Changes look good. If you don't have someone else to sponsor the > package, feel free to use me when you post APPROVED. Thanks. I know Warren had a comment on the Requires, but he hasn't found the time to respond yet. It was minor, so in the interest of getting the build going, I'll call it approved. As always, comments are still welcome. thx, josh From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 22 14:05:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Apr 2005 16:05:25 +0200 Subject: Request for review : moin Message-ID: <20050422160525.72fa5049@python2> Hi, I've imported in the devel CVS branch the MoinMoin package I've made by merging various existing ones. Please : - Review it now if you're interested in using it and post your comments. - Step up if you have strong feelings about maintaining it in Extras (I don't) and know you'll be good at it ;-) One last thing I actually thought of previously, but just realised I forgot, was to make the README.redhat a separate source instead of having it in the patch, in order to be able to update it more easily, and maybe rename it to something more generic like "README.rpm" too. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.12 0.38 0.38 From rc040203 at freenet.de Fri Apr 22 14:30:29 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 22 Apr 2005 16:30:29 +0200 Subject: Request for review : moin In-Reply-To: <20050422160525.72fa5049@python2> References: <20050422160525.72fa5049@python2> Message-ID: <1114180230.26656.106.camel@mccallum.corsepiu.local> On Fri, 2005-04-22 at 16:05 +0200, Matthias Saou wrote: > Hi, > > I've imported in the devel CVS branch the MoinMoin package I've made by > merging various existing ones. Please : - Review it now if you're > interested in using it and post your comments. Did you manage to resolve the char encoding issues with generic, i18n'd pages in MoinMoin? FC's apache defaults to utf-8 encoded pages, but the generic internationalized pages in MoinMoin are latin1 encoded. This for example shows in the "help pages" if using "de" or "fr" as preferred languages. An actual example of a server exposing this issue: In French http://www.fedoraproject.org/wiki/SommaireAide ... > * D?couvrez les pages d'aide les plus importantes : > > * AideAuxD?butants (HelpForBeginners) - si vous n'avez jamais > utilis? de wikis ... Or German http://www.fedoraproject.org/wiki/HilfeInhalt > * Hier ist eine ?bersicht ?ber die wichtigsten Hilfeseiten: > > * HilfeF?rAnf?nger - wenn Wikis noch neu f?r Sie sind In both cases, the server claims to be sending utf-8, while the contents is latin1. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 22 14:37:23 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Apr 2005 16:37:23 +0200 Subject: Request for review : moin In-Reply-To: <1114180230.26656.106.camel@mccallum.corsepiu.local> References: <20050422160525.72fa5049@python2> <1114180230.26656.106.camel@mccallum.corsepiu.local> Message-ID: <20050422163723.0f41b97e@python2> Ralf Corsepius wrote : > Did you manage to resolve the char encoding issues with generic, i18n'd > pages in MoinMoin? > > FC's apache defaults to utf-8 encoded pages, but the generic > internationalized pages in MoinMoin are latin1 encoded. I've just set up that rpm rebuilt for RHEL4, and I get proper accents on all words for the /mywiki/SommaireDeL'Aide page. I guess the easiest for you to know would be to simply try it on FC4 :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.03 0.24 0.26 From ed at eh3.com Fri Apr 22 14:40:31 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 22 Apr 2005 10:40:31 -0400 Subject: Review Request: NCO and CDO In-Reply-To: <1113839355.16955.273.camel@ernie> References: <1113839355.16955.273.camel@ernie> Message-ID: <1114180831.27414.140.camel@ernie> Hi folks (with a special plea to Spot!), I'd like to humbly request reviews of NCO and CDO. The former made it part-way through the "old" Fedora review process: https://bugzilla.fedora.us/show_bug.cgi?id=1893 and has been updated to fix (hopefully) all the outstanding problems from that earlier submission. The latter package (CDO) is quite similar to NCO but it offers some different (mostly complimentary) functionality including the ability to "re-grid" data sets. The packages are currently available at: http://mitgcm.org/eh3/fedora_misc/nco-3.0.0-1.src.rpm http://mitgcm.org/eh3/fedora_misc/cdo-0.9.6-1.src.rpm 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 a.kurtz at hardsun.net Fri Apr 22 14:44:27 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Fri, 22 Apr 2005 07:44:27 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <1114121002.4738.32.camel@localhost.localdomain> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> Message-ID: <1114181067.17549.4.camel@rydia.hardsun.net> On Thu, 2005-04-21 at 15:03 -0700, Per Bjornsson wrote: > On Thu, 2005-04-21 at 14:19 -0700, Aaron Kurtz wrote: > > Renamed, obsolete/provides added, and Ignacio's points fixed. The new > > spec is at: > > > > http://rydia.hardsun.net:8080/gnome-applet-netspeed.spec > > Spec looks fine to me now, and it builds/installs/uninstalls cleanly as > far as I can tell here (not rebuilt in a clean build root though, I > don't have one accessible right now; this is on FC3). Good, anyone want to sponsor this package so I can shoot an APPROVED over to fedora-extras-commits? > Possibly something for upstream: It didn't seem to detect that my > Atheros wireless card was wireless, it just showed a normal ethernet > card icon (I think it's supposed to be some kind of squiggle?) Traffic > measurement worked fine though. This should certainly not be a blocker > for putting it in Extras. Mmm, my wireless card at wlan0 gets the squiggle. Is your atheros a eth? card? Either way, you might want to mention it to the developer. -- Aaron Kurtz From carwyn at carwyn.com Fri Apr 22 14:48:03 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 22 Apr 2005 15:48:03 +0100 Subject: ViewCVS 1.0-dev RPM anywhere? Message-ID: <42690EA3.5020301@carwyn.com> I've seen dev versions of viewcvs 1.0 being used around the place for a while now (mainly for SVN support). Does anyone know od any RPMs of the dev snapshot that are available? Carwyn From tcallawa at redhat.com Fri Apr 22 14:56:22 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Apr 2005 09:56:22 -0500 Subject: Review needed: netspeed_applet In-Reply-To: <1114181067.17549.4.camel@rydia.hardsun.net> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> <1114181067.17549.4.camel@rydia.hardsun.net> Message-ID: <1114181783.3297.100.camel@localhost.localdomain> On Fri, 2005-04-22 at 07:44 -0700, Aaron Kurtz wrote: > On Thu, 2005-04-21 at 15:03 -0700, Per Bjornsson wrote: > > On Thu, 2005-04-21 at 14:19 -0700, Aaron Kurtz wrote: > > > Renamed, obsolete/provides added, and Ignacio's points fixed. The new > > > spec is at: > > > > > > http://rydia.hardsun.net:8080/gnome-applet-netspeed.spec > > > > Spec looks fine to me now, and it builds/installs/uninstalls cleanly as > > far as I can tell here (not rebuilt in a clean build root though, I > > don't have one accessible right now; this is on FC3). > > Good, anyone want to sponsor this package so I can shoot an APPROVED > over to fedora-extras-commits? E: gnome-applet-netspeed zero-length /usr/share/doc/gnome-applet-netspeed-0.12/NEWS Please take NEWS out of %doc, no need to drag 0 files around. :) Make that minor change, and its sponsored by me. > > Possibly something for upstream: It didn't seem to detect that my > > Atheros wireless card was wireless, it just showed a normal ethernet > > card icon (I think it's supposed to be some kind of squiggle?) Traffic > > measurement worked fine though. This should certainly not be a blocker > > for putting it in Extras. > > Mmm, my wireless card at wlan0 gets the squiggle. Is your atheros a eth? > card? Either way, you might want to mention it to the developer. My centrino (eth1) gets the network card icon. I wonder if its merely determining icon off device name, and not what that device name actually is. ~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 mpeters at mac.com Fri Apr 22 15:31:32 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 22 Apr 2005 15:31:32 +0000 Subject: Sponsor Request: jigdo In-Reply-To: <20050415210801.GA26472@angus.ind.WPI.EDU> (from cra@WPI.EDU on Fri Apr 15 14:08:01 2005) References: <20050415210801.GA26472@angus.ind.WPI.EDU> Message-ID: <1114183892l.8109l.0l@devel.mpeters.local> On 04/15/2005 02:08:01 PM, Chuck R. Anderson wrote: > I'd like to import jigdo into CVS. I've built and tested this on > FC3. I've got a crazy thought - I wonder if jigdo and bt could work together. I don't mean jigdo use bt, I mean use jigdo to create the .iso.tmp from rawhide packages on a machine, and then start up bittorent with the partial iso from jigdo. I'd like to try it with FC4T3 and see if bittorrent is able to work starting from an incomplete iso created by jigdo. If it does work, the benefit is that those with rawhide on their systems could use bt to get the rest of what they don't have, and bt would benefit because there would be more seeds early on. Chuck - are you planning to create a .jigdo file for test3? With test2 - jigdo found 85% of the files in my rawhide mirror (by file, not by size - I don't know by size) - if it works, I'll post instructions to the test list so that *possibly* fc4 release torrent could benefit. If it works, it certainly is better efficient use of bandwidth for peer seeding of the torrent. I know that bad downloads can be fixed via bittorent (the client will scan it, throw away the bad parts, and refetch them) so I think it might work. -- Michael A. Peters http://mpeters.us/ From skvidal at phy.duke.edu Fri Apr 22 15:32:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Apr 2005 11:32:27 -0400 Subject: Request for review : moin In-Reply-To: <20050422163723.0f41b97e@python2> References: <20050422160525.72fa5049@python2> <1114180230.26656.106.camel@mccallum.corsepiu.local> <20050422163723.0f41b97e@python2> Message-ID: <1114183947.3489.7.camel@cutter> On Fri, 2005-04-22 at 16:37 +0200, Matthias Saou wrote: > Ralf Corsepius wrote : > > > Did you manage to resolve the char encoding issues with generic, i18n'd > > pages in MoinMoin? > > > > FC's apache defaults to utf-8 encoded pages, but the generic > > internationalized pages in MoinMoin are latin1 encoded. > > I've just set up that rpm rebuilt for RHEL4, and I get proper accents on > all words for the /mywiki/SommaireDeL'Aide page. I guess the easiest for > you to know would be to simply try it on FC4 :-) Ralf is complaining about a bug in 1.2.X. It shows up on th fedoraproject wiki b/c it is running 1.2.X. It's running 1.2.X b/c I've not had an opportunity to upgrade it and migrate the data. -sv From perbj at stanford.edu Fri Apr 22 16:13:42 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 22 Apr 2005 09:13:42 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <1114181783.3297.100.camel@localhost.localdomain> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> <1114181067.17549.4.camel@rydia.hardsun.net> <1114181783.3297.100.camel@localhost.localdomain> Message-ID: <1114186423.4587.6.camel@localhost.localdomain> On Fri, 2005-04-22 at 09:56 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-04-22 at 07:44 -0700, Aaron Kurtz wrote: > > Mmm, my wireless card at wlan0 gets the squiggle. Is your atheros a eth? > > card? Either way, you might want to mention it to the developer. > > My centrino (eth1) gets the network card icon. I wonder if its merely > determining icon off device name, and not what that device name actually > is. The Atheros Madwifi driver enjoys being special and calls the device ath0. It really sounds like "known names" (wlanX for the wireless case) get specific icons and the others get the network card by default. I'll bring this up with the developer. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From skvidal at phy.duke.edu Fri Apr 22 16:15:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Apr 2005 12:15:35 -0400 Subject: make tag request Message-ID: <1114186536.3489.15.camel@cutter> Hey folks, Everyone who has a build request on the fc3 or fc4 wiki pages PLEASE run make tag on your package(s). thanks, -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 22 16:43:06 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Apr 2005 18:43:06 +0200 Subject: Review needed: netspeed_applet In-Reply-To: <1114186423.4587.6.camel@localhost.localdomain> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> <1114181067.17549.4.camel@rydia.hardsun.net> <1114181783.3297.100.camel@localhost.localdomain> <1114186423.4587.6.camel@localhost.localdomain> Message-ID: <20050422184306.11288653@python2> Per Bjornsson wrote : > On Fri, 2005-04-22 at 09:56 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2005-04-22 at 07:44 -0700, Aaron Kurtz wrote: > > > Mmm, my wireless card at wlan0 gets the squiggle. Is your atheros a eth? > > > card? Either way, you might want to mention it to the developer. > > > > My centrino (eth1) gets the network card icon. I wonder if its merely > > determining icon off device name, and not what that device name actually > > is. > > The Atheros Madwifi driver enjoys being special and calls the device > ath0. It really sounds like "known names" (wlanX for the wireless case) > get specific icons and the others get the network card by default. I'll > bring this up with the developer. Then easy workaround for this particular case : alias wlan0 ipw2100 options ipw2100 ifname=wlan%d Or ipw2200 depending on your card. I like having wlan0. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.18 0.43 0.55 From michal at harddata.com Fri Apr 22 17:16:32 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 22 Apr 2005 11:16:32 -0600 Subject: Review needed: netspeed_applet In-Reply-To: <1114186423.4587.6.camel@localhost.localdomain>; from perbj@stanford.edu on Fri, Apr 22, 2005 at 09:13:42AM -0700 References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> <1114181067.17549.4.camel@rydia.hardsun.net> <1114181783.3297.100.camel@localhost.localdomain> <1114186423.4587.6.camel@localhost.localdomain> Message-ID: <20050422111632.B6153@mail.harddata.com> On Fri, Apr 22, 2005 at 09:13:42AM -0700, Per Bjornsson wrote: > > The Atheros Madwifi driver enjoys being special and calls the device > ath0. It really sounds like "known names" (wlanX for the wireless case) > get specific icons and the others get the network card by default. There is really not much which can stop you from renaming your network interfaces in many different ways with a help of 'nameif'. I would think that "ath0" or "wlanX" strings are not exceptional here although that I never tried. Maybe this facility is not used very widely but it is used and for good reasons. Therefore it is definitely a bad juju in various networking tools to rely on some specific "known names". > I'll bring this up with the developer. Sounds like a good plan. Michal From tcallawa at redhat.com Fri Apr 22 17:42:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Apr 2005 12:42:06 -0500 Subject: Sponsor and review request: c-ares Message-ID: <1114191727.3297.126.camel@localhost.localdomain> As prodded by Ed, I started to review NCO, and I discovered that it was looking for some optional dependencies. Since history has taught me that the number one complaint from developers and users (other than that Red Hat is an evil corporation, seeking to be the next Microsoft) is that we didn't compile foo with support for bar. So, I've started down the path of providing dependencies. First we've got c-ares. c-ares is a C library that performs DNS requests and name resolves asynchronously. c-ares is a fork of the library named 'ares', written by Greg Hudson at MIT. c-ares: SPEC: http://www.auroralinux.org/people/spot/review/c-ares.spec SRPM: http://www.auroralinux.org/people/spot/review/c-ares-1.2.1-1.src.rpm ~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 perbj at stanford.edu Fri Apr 22 17:52:25 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 22 Apr 2005 10:52:25 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <20050422111632.B6153@mail.harddata.com> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> <1114181067.17549.4.camel@rydia.hardsun.net> <1114181783.3297.100.camel@localhost.localdomain> <1114186423.4587.6.camel@localhost.localdomain> <20050422111632.B6153@mail.harddata.com> Message-ID: <1114192345.4746.15.camel@localhost.localdomain> On Fri, 2005-04-22 at 11:16 -0600, Michal Jaegermann wrote: > On Fri, Apr 22, 2005 at 09:13:42AM -0700, Per Bjornsson wrote: > > > > The Atheros Madwifi driver enjoys being special and calls the device > > ath0. It really sounds like "known names" (wlanX for the wireless case) > > get specific icons and the others get the network card by default. > > There is really not much which can stop you from renaming your > network interfaces in many different ways with a help of 'nameif'. > I would think that "ath0" or "wlanX" strings are not exceptional > here although that I never tried. They certainly aren't exceptional; there's loads of variability even in the driver defaults (ethX for orinoco and apparently ipw2100?, athX for Atheros, raX for some Ralink versions at least, acx100 defaults to wlanX but has a module parameter switch to change that to ethX...) > Maybe this facility is not used > very widely but it is used and for good reasons. Therefore it is > definitely a bad juju in various networking tools to rely on some > specific "known names". Oh, absolutely, that was the point I was initially trying to make! In fact, I think that the most used (if not all?) wireless drivers in the kernel (at least the orinoco driver which I have used) name the cards eth0 by default; "wlan0" might be inherited from the wavelan driver. Relying on the name of a device is inherently broken. Luckily, it's not really used for anything terribly important here, just for choosing the shown icon; the applet doesn't behave differently depending on the type of interface apart from that. If it actually did any real harm I would have been less happy to see the package included as is. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From kaboom at oobleck.net Fri Apr 22 17:57:28 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 22 Apr 2005 13:57:28 -0400 (EDT) Subject: Sponsor and review request: c-ares In-Reply-To: <1114191727.3297.126.camel@localhost.localdomain> References: <1114191727.3297.126.camel@localhost.localdomain> Message-ID: On Fri, 22 Apr 2005, Tom 'spot' Callaway wrote: > c-ares: > SPEC: http://www.auroralinux.org/people/spot/review/c-ares.spec > SRPM: > http://www.auroralinux.org/people/spot/review/c-ares-1.2.1-1.src.rpm Looks good to me, other than the license. It appears to be MIT, not LGPL. Also, is it necessary to include: %{_libdir}/libcares.la ? later, chris From ed at eh3.com Fri Apr 22 18:09:56 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 22 Apr 2005 14:09:56 -0400 Subject: Sponsor and review request: c-ares In-Reply-To: References: <1114191727.3297.126.camel@localhost.localdomain> Message-ID: <1114193397.27414.154.camel@ernie> On Fri, 2005-04-22 at 13:57 -0400, Chris Ricker wrote: > On Fri, 22 Apr 2005, Tom 'spot' Callaway wrote: > > > c-ares: > > SPEC: http://www.auroralinux.org/people/spot/review/c-ares.spec > > SRPM: > > http://www.auroralinux.org/people/spot/review/c-ares-1.2.1-1.src.rpm > > Looks good to me, other than the license. It appears to be MIT, > not LGPL. > Also, is it necessary to include: > > %{_libdir}/libcares.la Hi Chris, I don't think the *.la file is necessary. Under what circumstances would anyone use it? So the package looks fine to me. The only nit I noticed was the lack of a Summary: line for the non-devel package. It also builds, installs, un-installs, and otherwise works-for-me on an FC-3 system. 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 Fri Apr 22 18:47:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Apr 2005 13:47:16 -0500 Subject: Sponsor and review request: c-ares In-Reply-To: <1114193397.27414.154.camel@ernie> References: <1114191727.3297.126.camel@localhost.localdomain> <1114193397.27414.154.camel@ernie> Message-ID: <1114195636.3297.138.camel@localhost.localdomain> On Fri, 2005-04-22 at 14:09 -0400, Ed Hill wrote: > So the package looks fine to me. The only nit I noticed was the lack of > a Summary: line for the non-devel package. > > It also builds, installs, un-installs, and otherwise works-for-me on an > FC-3 system. Umm, line 1? Summary: A library that performs asynchronous DNS operations :) Other fixes (license, remove .la) done: SPEC: http://www.auroralinux.org/people/spot/review/c-ares.spec SRPM: http://www.auroralinux.org/people/spot/review/c-ares-1.2.1-2.src.rpm Please review (and sponsor) this. In a lovely twist of irony, this package didn't end up being a requisite, but its built, its small... ~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 kaboom at oobleck.net Fri Apr 22 19:22:00 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 22 Apr 2005 15:22:00 -0400 (EDT) Subject: Sponsor and review request: c-ares In-Reply-To: <1114195636.3297.138.camel@localhost.localdomain> References: <1114191727.3297.126.camel@localhost.localdomain> <1114193397.27414.154.camel@ernie> <1114195636.3297.138.camel@localhost.localdomain> Message-ID: On Fri, 22 Apr 2005, Tom 'spot' Callaway wrote: > Other fixes (license, remove .la) done: > > SPEC: http://www.auroralinux.org/people/spot/review/c-ares.spec > SRPM: > http://www.auroralinux.org/people/spot/review/c-ares-1.2.1-2.src.rpm > > Please review (and sponsor) this. Looks good to me. I'll sponsor it > In a lovely twist of irony, this package didn't end up being a > requisite, but its built, its small... I actually have a package which can use it, so it worked out quite well that you packaged it.... later, chris From mricon at gmail.com Fri Apr 22 19:58:59 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Fri, 22 Apr 2005 15:58:59 -0400 Subject: Suggestion: pylint Message-ID: Hello, everyone: Pylint is a useful tool for extra-anal Python code analysis for errors and poor habits. It is used by PyDev in Eclipse if available (PyDev is part of FC4), so I think it's good if Pylint is added to Extras. I have created the RPMs for the first looking-over. See: http://phy.duke.edu/~icon/misc/fedora-extras/ Pylint requires common libraries from Logilab, so they are packaged as python-logilab-common. URL: http://www.logilab.org/projects/pylint Any objections or suggestions? Regards, -- Konstantin Ryabitsev Zlotniks, INC From ivazquez at ivazquez.net Fri Apr 22 20:05:07 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 22 Apr 2005 16:05:07 -0400 Subject: Review needed: netspeed_applet In-Reply-To: <1114084499.6921.17.camel@rydia.hardsun.net> References: <1114084499.6921.17.camel@rydia.hardsun.net> Message-ID: <1114200307.7784.12.camel@ignacio.ignacio.lan> I recommend an update to 0.12.1. Apparently this will solve the pkg- config issue you were seeing. -- 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 cra at WPI.EDU Fri Apr 22 20:26:14 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 22 Apr 2005 16:26:14 -0400 Subject: Sponsor Request: jigdo In-Reply-To: <1114183892l.8109l.0l@devel.mpeters.local> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <1114183892l.8109l.0l@devel.mpeters.local> Message-ID: <20050422202614.GE19758@angus.ind.WPI.EDU> On Fri, Apr 22, 2005 at 03:31:32PM +0000, Michael A. Peters wrote: > I wonder if jigdo and bt could work together. I don't mean jigdo use > bt, I mean use jigdo to create the .iso.tmp from rawhide packages on a > machine, and then start up bittorent with the partial iso from jigdo. What is a .tmp file in this context? > I'd like to try it with FC4T3 and see if bittorrent is able to work > starting from an incomplete iso created by jigdo. jigdo can create the complete iso, though. > If it does work, the benefit is that those with rawhide on their > systems could use bt to get the rest of what they don't have, and bt > would benefit because there would be more seeds early on. Did you see the thread on fedora-test-list? I did exactly what you suggest, but using jigdo to create the iso. You could then start bt on the iso to provide a seed. > Chuck - are you planning to create a .jigdo file for test3? Yes. > With test2 - jigdo found 85% of the files in my rawhide mirror (by > file, not by size - I don't know by size) - if it works, I'll post > instructions to the test list so that *possibly* fc4 release torrent > could benefit. If it works, it certainly is better efficient use of > bandwidth for peer seeding of the torrent. > > I know that bad downloads can be fixed via bittorent (the client will > scan it, throw away the bad parts, and refetch them) so I think it > might work. It should work. There should be no reason that bittorrent would need to fix a bad download, because the .iso created by jigdo should be complete and md5/sha1 correct. From ed at eh3.com Fri Apr 22 21:21:28 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 22 Apr 2005 17:21:28 -0400 Subject: Sponsor and review request: c-ares In-Reply-To: <1114195636.3297.138.camel@localhost.localdomain> References: <1114191727.3297.126.camel@localhost.localdomain> <1114193397.27414.154.camel@ernie> <1114195636.3297.138.camel@localhost.localdomain> Message-ID: <1114204889.27414.168.camel@ernie> On Fri, 2005-04-22 at 13:47 -0500, Tom 'spot' Callaway wrote: > On Fri, 2005-04-22 at 14:09 -0400, Ed Hill wrote: > > > So the package looks fine to me. The only nit I noticed was the lack of > > a Summary: line for the non-devel package. > > > > It also builds, installs, un-installs, and otherwise works-for-me on an > > FC-3 system. > > Umm, line 1? > Summary: A library that performs asynchronous DNS operations Darn, let me wipe this egg off my face... there! Much better. ;-) 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 a.kurtz at hardsun.net Sat Apr 23 00:02:23 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Fri, 22 Apr 2005 17:02:23 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <1114200307.7784.12.camel@ignacio.ignacio.lan> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114200307.7784.12.camel@ignacio.ignacio.lan> Message-ID: <1114214543.17549.15.camel@rydia.hardsun.net> On Fri, 2005-04-22 at 16:05 -0400, Ignacio Vazquez-Abrams wrote: > I recommend an update to 0.12.1. Apparently this will solve the pkg- > config issue you were seeing. Yes, the .1 release was due to my discussion with the developer. The spec has been updated, and will be put in CVS tonight. -- Aaron Kurtz From mfleming at enlartenment.com Sat Apr 23 01:08:47 2005 From: mfleming at enlartenment.com (Michael Fleming) Date: Sat, 23 Apr 2005 11:08:47 +1000 Subject: Request for review: mlmmj In-Reply-To: <1113736625.11362.11.camel@defender.antaresenterprises.lan> References: <1113736625.11362.11.camel@defender.antaresenterprises.lan> Message-ID: <20050423110847.3bd70a8c.mfleming@enlartenment.com> On Sun, 17 Apr 2005 21:17:05 +1000. Michael Fleming > waffled thusly: > Hi, > > Would anyone wish to review / sponsor the MLMMJ mailing list manager > software? (http://mlmmj.mmj.dk/) . It's an ezmlm-like mailing list > manager intended for use with Postfix or Exim (Possibly Sendmail too but > I've not tried, being a longtime Postfix aficionado ;-)) > > http://www.enlartenment.com/packages/fedora/3/i386/SRPMS.mf/mlmmj-1.2.4-3.fc3.mf.src.rpm I've refined this a little more and put the sources + spec + SRPM at http://www.enlartenment.com/packages/extras/ If anyone would like to review / sponsor this for inclusion. Thanks in advance. Michael. -- Michael Fleming "Bother" said the Borg, "We've assimilated Pooh!" From a.kurtz at hardsun.net Sat Apr 23 01:25:50 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Fri, 22 Apr 2005 18:25:50 -0700 Subject: Review needed: netspeed_applet In-Reply-To: <20050422111632.B6153@mail.harddata.com> References: <1114084499.6921.17.camel@rydia.hardsun.net> <1114105229.4738.12.camel@localhost.localdomain> <1114118346.6921.24.camel@rydia.hardsun.net> <1114121002.4738.32.camel@localhost.localdomain> <1114181067.17549.4.camel@rydia.hardsun.net> <1114181783.3297.100.camel@localhost.localdomain> <1114186423.4587.6.camel@localhost.localdomain> <20050422111632.B6153@mail.harddata.com> Message-ID: <1114219550.17952.1.camel@rydia.hardsun.net> On Fri, 2005-04-22 at 11:16 -0600, Michal Jaegermann wrote: > > There is really not much which can stop you from renaming your > network interfaces in many different ways with a help of 'nameif'. > I would think that "ath0" or "wlanX" strings are not exceptional > here although that I never tried. Maybe this facility is not used > very widely but it is used and for good reasons. Therefore it is > definitely a bad juju in various networking tools to rely on some > specific "known names". > > > I'll bring this up with the developer. > > Sounds like a good plan. I've mentioned it to him, and yes, icons are given out by interface name. He's got doing it by HAL information on his todo list, but considering it only changes the icon, -- Aaron Kurtz From mpeters at mac.com Sat Apr 23 04:29:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 04:29:14 +0000 Subject: Suggestion: pylint In-Reply-To: (from mricon@gmail.com on Fri Apr 22 12:58:59 2005) References: Message-ID: <1114230554l.2872l.0l@devel.mpeters.local> On 04/22/2005 12:58:59 PM, Konstantin Ryabitsev wrote: > Hello, everyone: > > Pylint is a useful tool for extra-anal Python code analysis for > errors > and poor habits. It is used by PyDev in Eclipse if available (PyDev > is > part of FC4), so I think it's good if Pylint is added to Extras. > > I have created the RPMs for the first looking-over. See: > http://phy.duke.edu/~icon/misc/fedora-extras/ I believe extras wants you to %ghost the *.pyo files in site-packages -- Michael A. Peters http://mpeters.us/ From ivazquez at ivazquez.net Sat Apr 23 07:27:23 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 23 Apr 2005 03:27:23 -0400 Subject: Review/sponsor needed: sqlite2 Message-ID: <1114241243.7784.17.camel@ignacio.ignacio.lan> Reposting this by request. http://fedora.ivazquez.net/files/sqlite2.spec -- 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 all-the-johnsons.co.uk Sat Apr 23 10:42:38 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 23 Apr 2005 11:42:38 +0100 Subject: Request for addition : mysqlcc Message-ID: <1114252958.4480.1.camel@localhost> Hi, What's the procedure I have to go through to get an application into extras? I think it would be of great benefit to include mysqlcc in and I don't mind maintaining it. http://dev.mysql.com/downloads/other/mysqlcc.html TTFN Paul -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 kaboom at oobleck.net Sat Apr 23 11:21:58 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 23 Apr 2005 07:21:58 -0400 (EDT) Subject: request for review: tre Message-ID: tre is primarily a POSIX-compliant regexp library, but with support for arbitrarily approximate matching. The package also includes agrep, a fuzzy grep built using this library. Anyone care to review / sponsor? later, chris From kaboom at oobleck.net Sat Apr 23 12:29:43 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 23 Apr 2005 08:29:43 -0400 (EDT) Subject: request for review: xdaliclock Message-ID: Anyone want to review / sponsor? later, chris From mpeters at mac.com Sat Apr 23 14:03:50 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 07:03:50 -0700 Subject: Request for Review - PyRTF In-Reply-To: <1113416123.12065.10.camel@ignacio.ignacio.lan> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <1113413738.17039.0.camel@fc4t2.mpeters.local> <1113416123.12065.10.camel@ignacio.ignacio.lan> Message-ID: <1114265030.30340.9.camel@fc4t2.mpeters.local> On Wed, 2005-04-13 at 14:15 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-13 at 10:35 -0700, Michael Peters wrote: > > On Wed, 2005-04-13 at 05:33 -0400, Ignacio Vazquez-Abrams wrote: > > > On Wed, 2005-04-13 at 02:14 -0700, Michael Peters wrote: > > > > My spec file - http://mpeters.us/fc_extras/PyRTF.spec > > > > > > ? Source0 should have a complete URL if possible (e.g., > > > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) > > > - BR should be python, not python-devel > > > - Dir %{python_sitelib}/PyRTF not owned by package > > > - Should have [E:]V-R on every changelog entry > > > > Thanks - fixed > > You missed the BR. noarch Python packages only need distutils, not the > whole includes/libs set. And distutils comes in the base python package. New specfile, upstream fixed the locale stuff so I don't have to patch that anymore, I also (after reading through wiki) changed the Source0 to not use macros so that testers can wget cut-n-paste to verify package. -=- New files: http://mpeters.us/fc_extras/gourmet.spec http://mpeters.us/fc_extras/gourmet-0.8.3.4-1.src.rpm http://mpeters.us/fc_extras/gourmet-0.8.3.4.desktop.patch The dependency not in core/extras (PyRTF) is another package I've asked for review elsewhere. Yes - I neglected BuildRequires for desktop-file-install. That will be fixed with next upload. With next upload I also will change the desktop.patch to not modify the setup.py script, and instead %ghost the desktop file it installs (but patch still needed for the desktop file itself) From mpeters at mac.com Sat Apr 23 14:07:00 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 07:07:00 -0700 Subject: Request for Review - PyRTF In-Reply-To: <1113416123.12065.10.camel@ignacio.ignacio.lan> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <1113413738.17039.0.camel@fc4t2.mpeters.local> <1113416123.12065.10.camel@ignacio.ignacio.lan> Message-ID: <1114265221.30340.11.camel@fc4t2.mpeters.local> On Wed, 2005-04-13 at 14:15 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-13 at 10:35 -0700, Michael Peters wrote: > > On Wed, 2005-04-13 at 05:33 -0400, Ignacio Vazquez-Abrams wrote: > > > On Wed, 2005-04-13 at 02:14 -0700, Michael Peters wrote: > > > > My spec file - http://mpeters.us/fc_extras/PyRTF.spec > > > > > > ? Source0 should have a complete URL if possible (e.g., > > > http://prdownloads.sourceforge.net/pyrtf/PyRTF-0.43.tar.gz) > > > - BR should be python, not python-devel > > > - Dir %{python_sitelib}/PyRTF not owned by package > > > - Should have [E:]V-R on every changelog entry > > > > Thanks - fixed > > You missed the BR. noarch Python packages only need distutils, not the > whole includes/libs set. And distutils comes in the base python package. My apologies - my last reply was with respect to a different package. Current PyRTF spec file and package: http://mpeters.us/fc_extras/PyRTF.spec http://mpeters.us/fc_extras/PyRTF-0.43-1.src.rpm From mpeters at mac.com Sat Apr 23 14:09:34 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 07:09:34 -0700 Subject: Sponsor Request: jigdo In-Reply-To: <20050422202614.GE19758@angus.ind.WPI.EDU> References: <20050415210801.GA26472@angus.ind.WPI.EDU> <1114183892l.8109l.0l@devel.mpeters.local> <20050422202614.GE19758@angus.ind.WPI.EDU> Message-ID: <1114265374.30340.14.camel@fc4t2.mpeters.local> On Fri, 2005-04-22 at 16:26 -0400, Chuck R. Anderson wrote: > > It should work. There should be no reason that bittorrent would need > to fix a bad download, because the .iso created by jigdo should be > complete and md5/sha1 correct. Yes - but by using the torrent to complete the iso, it would also feed the torrent with the bits that jigdo-lite had found while it was grabbing the bits that it needed. From mpeters at mac.com Sat Apr 23 14:13:06 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 07:13:06 -0700 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <20050417055650.A10311@tiki-lounge.com> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> Message-ID: <1114265586.30340.18.camel@fc4t2.mpeters.local> On Sun, 2005-04-17 at 05:56 -0700, Toshio Kuratomi wrote: > If the patch is as short as you describe, upstream would probably be willing > to consider it I contacted developer and he did in fact update his source to use /usr/share/locale/ on posix systems. So it's all good now. http://mpeters.us/fc_extras/gourmet.spec http://mpeters.us/fc_extras/gourmet-0.8.3.4-1.src.rpm http://mpeters.us/fc_extras/gourmet-0.8.3.4.desktop.patch From tcallawa at redhat.com Sat Apr 23 15:05:30 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 10:05:30 -0500 Subject: Sponsor and review request: opendap, librx Message-ID: <1114268730.3297.161.camel@localhost.localdomain> Last two bits in the dependency chain for NCO: librx and opendap (also called "DODS"). librx: Rx is, among other things, an implementation of the interface specified by POSIX for programming with regular expressions. Some other implementations are GNU regex.c and Henry Spencer's regex library. URL: http://www.gnu.org/software/rx/rx.html SRPM: http://www.auroralinux.org/people/spot/review/librx-1.5-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/librx.spec opendap: OPeNDAP provides software which makes local data accessible to remote locations regardless of local storage format. OPeNDAP also provides tools for transforming existing applications into OPeNDAP clients (i.e., enabling them to remotely access OPeNDAP served data). OPeNDAP software is freely available. URL: http://www.opendap.org/ SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-1.src.rpm SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec Please help me sponsor and review these packages, so I can sponsor and review NCO. ;) ~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 Sat Apr 23 15:10:13 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 10:10:13 -0500 Subject: Review Request: NCO and CDO In-Reply-To: <1114180831.27414.140.camel@ernie> References: <1113839355.16955.273.camel@ernie> <1114180831.27414.140.camel@ernie> Message-ID: <1114269014.3297.167.camel@localhost.localdomain> On Fri, 2005-04-22 at 10:40 -0400, Ed Hill wrote: > Hi folks (with a special plea to Spot!), > > I'd like to humbly request reviews of NCO and CDO. The former made it > part-way through the "old" Fedora review process: > > https://bugzilla.fedora.us/show_bug.cgi?id=1893 > > and has been updated to fix (hopefully) all the outstanding problems > from that earlier submission. It does look like the outstanding problems from the b.f.u ticket have been resolved. A couple of items I found: +BuildRequires: udunits, udunits-devel +BuildRequires: curl-devel, libxml2-devel, opendap-devel, librx-devel You're missing some BuildRequires. (Note that opendap-devel and librx-devel are pending sponsorship and review.) -export CXXFLAGS='-fpermissive' +export CXXFLAGS="$RPM_OPT_FLAGS -fpermissive" No reason I can see to drop the optimization flags entirely, it builds great with them in rawhide. You also need to apply one more package for udunits to work properly. This patch is attached to the email. ~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! -------------- next part -------------- A non-text attachment was scrubbed... Name: nco-3.0.0-fixudunits.patch Type: text/x-patch Size: 811 bytes Desc: not available URL: From adrian at lisas.de Sat Apr 23 15:58:30 2005 From: adrian at lisas.de (Adrian Reber) Date: Sat, 23 Apr 2005 17:58:30 +0200 Subject: packages for review: openbox and friends In-Reply-To: References: <20050420052915.GA11961@lisas.de> Message-ID: <20050423155830.GB9919@lisas.de> > There are errors when trying to build it with mach: checking for glib-2.0... Package glib-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `glib-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'glib-2.0' found configure: error: Library requirements (glib-2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. error: Bad exit status from /var/tmp/rpm-tmp.68474 (%build) You need to add glib2-devel, libxml2-devel and startup-notification-devel as BuildRequires and can then remove the XFree86-devel BR because that will be pulled in by startup-notification-devel. The same is true for fontconfig-devel as it is pulled in by xorg-x11-devel: BuildRequires: bison libxml2-devel BuildRequires: startup-notification-devel glib2-devel %post and %postun could be %post(un) -p /sbin/ldconfig and you can then remove Requires(post(un)): /sbin/ldconfig I have seen in other reviews that install should use the -p flag to preserve timestamps. And maybe you could use either cp or install and not mix it. But that is up to you. Adrian -- Adrian Reber http://lisas.de/~adrian/ Mommy, what happens to your files when you die? From tcallawa at redhat.com Sat Apr 23 17:59:43 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 12:59:43 -0500 Subject: Review Request: NCO and CDO In-Reply-To: <1114180831.27414.140.camel@ernie> References: <1113839355.16955.273.camel@ernie> <1114180831.27414.140.camel@ernie> Message-ID: <1114279183.9001.3.camel@localhost.localdomain> On Fri, 2005-04-22 at 10:40 -0400, Ed Hill wrote: > The latter package (CDO) is quite similar to NCO but it offers some > different (mostly complimentary) functionality including the ability to > "re-grid" data sets. CDO looks good, one minor change: Use this instead of what you have... no reason to not use the OPT_FLAGS. export CPPFLAGS="$RPM_OPT_FLAGS -I/usr/include/netcdf-3" ~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 toshio at tiki-lounge.com Sat Apr 23 18:46:12 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 23 Apr 2005 14:46:12 -0400 Subject: Request for Review - PyRTF In-Reply-To: <1114265221.30340.11.camel@fc4t2.mpeters.local> References: <1113383674.9991.5.camel@fc4t2.mpeters.local> <1113384834.12065.5.camel@ignacio.ignacio.lan> <1113413738.17039.0.camel@fc4t2.mpeters.local> <1113416123.12065.10.camel@ignacio.ignacio.lan> <1114265221.30340.11.camel@fc4t2.mpeters.local> Message-ID: <1114281973.4282.9.camel@Madison.badger.com> On Sat, 2005-04-23 at 07:07 -0700, Michael A. Peters wrote: > On Wed, 2005-04-13 at 14:15 -0400, Ignacio Vazquez-Abrams wrote: > > You missed the BR. noarch Python packages only need distutils, not the > > whole includes/libs set. And distutils comes in the base python package. > > My apologies - my last reply was with respect to a different package. > > Current PyRTF spec file and package: > > http://mpeters.us/fc_extras/PyRTF.spec > http://mpeters.us/fc_extras/PyRTF-0.43-1.src.rpm > When updating a package, even for these initial pre-release, you should update the release and changelog. -Toshio -- toshio \ Questions for the Would Morticia wear it? @tiki- \ 21st Century! Would it look better on me? lounge.com=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ GA->ME 1999 -------------- 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 Sat Apr 23 18:49:45 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 23 Apr 2005 14:49:45 -0400 Subject: Sponsor and review request: opendap, librx In-Reply-To: <1114268730.3297.161.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> Message-ID: <1114282186.17203.60.camel@ernie> On Sat, 2005-04-23 at 10:05 -0500, Tom 'spot' Callaway wrote: > Last two bits in the dependency chain for NCO: librx and opendap (also > called "DODS"). Hi Tom, Very nice! A lot of progress in just a few days! I'm really happy to see all these things getting packaged for Fedora Extras. > librx: > URL: http://www.gnu.org/software/rx/rx.html > SRPM: http://www.auroralinux.org/people/spot/review/librx-1.5-1.src.rpm I'd like to sponsor rx. Its small, everything appears to be in order, and it works-for-me (builds, installs, etc.) on an updated devel system. > opendap: > SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-1.src.rpm > SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec I've read the entire spec file and can't find anything wrong with it. But then, I'm not a experienced reviewer. The build emitted warnings about the redefinition of printf and related functions. So I looked into the source and found that opendap includes versions of the following: included in OPeNDAP: currently in devel: curl 7.12.0 7.13.1 libxml2 pre-2.5.7 (?) 2.6.19 zlib 1.1.4 1.2.2.2 which seems a little fishy. I know that there have been past zlib security patches: https://rhn.redhat.com/errata/RHSA-2003-081.html http://www.gzip.org/zlib/advisory-2002-03-11.txt but perhaps the included 1.1.4 version is new enough that all known problems are fixed. And perhaps the versions of curl and libxml2 are also sufficiently up-to-date. In terms of both policy and practical considerations, is it OK to allow packages (like OPeNDAP) to include their own versions of some libs? Or should we patch their build system(s) to use the versions provided by the "official" RPMs? 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 bugs.michael at gmx.net Sat Apr 23 19:20:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Apr 2005 21:20:59 +0200 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <1114241243.7784.17.camel@ignacio.ignacio.lan> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> Message-ID: <20050423212059.11deb9da.bugs.michael@gmx.net> On Sat, 23 Apr 2005 03:27:23 -0400, Ignacio Vazquez-Abrams wrote: > Reposting this by request. > > http://fedora.ivazquez.net/files/sqlite2.spec It's okay. Diff against sqlite-2_8_16-2 is good. A few additional comments on SQLite v2 versus v3: * SQLite v3 file format is incompatible with v2. Databases need to be converted with sqlite utility. And with regard to any plans on upgrading the FC-3 branch, comments on sqlite v2 dependencies: * Package "kannel": not built for FC3 * Package "moodss": current FC3 binaries not built with sqlite-tcl * Package "php-pecl-sqlite": built with internal sqlite 2.8.14 * Package "python-sqlite" in FC-3 branch: no deps which use it -------------- 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 Sat Apr 23 19:29:32 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Apr 2005 21:29:32 +0200 Subject: Sponsor and review request: opendap, librx In-Reply-To: <1114268730.3297.161.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> Message-ID: <20050423212932.26bcae86.bugs.michael@gmx.net> On Sat, 23 Apr 2005 10:05:30 -0500, Tom 'spot' Callaway wrote: > opendap: > OPeNDAP provides software which makes local data accessible to remote > locations regardless of local storage format. OPeNDAP also provides > tools for transforming existing applications into OPeNDAP clients (i.e., > enabling them to remotely access OPeNDAP served data). OPeNDAP software > is freely available. > > URL: http://www.opendap.org/ > SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-1.src.rpm > SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec > > Please help me sponsor and review these packages, so I can sponsor and > review NCO. ;) > BuildRequires: openssl, pkgconfig > BuildRequires: curl, krb5-libs Please double-check whether this should be BuildRequires: openssl-devel curl-devel pkgconfig > %install > rm -rf ${RPM_BUILD_ROOT} > cd DODS/ > # move the docs to the toplevel > mv ChangeLog INSTALL NEWS VERSION README ../ Not a blocker, since you're going to maintain this. But *please* try not to break --short-circuit rpmbuild installs as they are really very useful for debugging %install/%files sections. As a rule of thumb, don't move/delete files below $RPM_BUILD_DIR. Where needed, copy files to temporary directories. But don't delete or move them. > %post devel > /sbin/ldconfig > > %postun devel > /sbin/ldconfig Missing dependencies on /sbin/ldconfig then, which is unlikely to not be installed already. But well... From jfontain at free.fr Sat Apr 23 20:07:13 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sat, 23 Apr 2005 22:07:13 +0200 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <20050423212059.11deb9da.bugs.michael@gmx.net> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> Message-ID: <426AAAF1.5070503@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > * Package "moodss": current FC3 binaries not built with sqlite-tcl To be precise: moodss does not include sqlite-tcl, moodss 17.17 in extras does not require it but will use it if installed, whereas more recent versions (not in extras yet) require it (or will require sqlite2-tcl). - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCaqrxkG/MMvcT1qQRAguJAJ0W/CnMaNvDNYj/mqNRfeaMTAxe2ACgoIkG ba39pYY6DwzDXteS+GV4SEQ= =Ez5X -----END PGP SIGNATURE----- From a.kurtz at hardsun.net Sat Apr 23 20:52:44 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Sat, 23 Apr 2005 13:52:44 -0700 Subject: request for review: xdaliclock In-Reply-To: References: Message-ID: <1114289564.30784.6.camel@rydia.hardsun.net> On Sat, 2005-04-23 at 08:29 -0400, Chris Ricker wrote: > > > Anyone want to review / sponsor? Builds, installs, runs on FC4t2. Wasn't this in RH before and therefore technically doesn't need a sponsor? Of course, that was back in 7.3 or so. >Source0: http://www.jwz.org/xdaliclock/xdaliclock-%{version}.tar.gz Isn't the convention to have the source not use macros? -- Aaron Kurtz In-Reply-To: <1114252958.4480.1.camel@localhost> References: <1114252958.4480.1.camel@localhost> Message-ID: <1114289869.30784.8.camel@rydia.hardsun.net> On Sat, 2005-04-23 at 11:42 +0100, Paul wrote: > What's the procedure I have to go through to get an application into > extras? I think it would be of great benefit to include mysqlcc in and I > don't mind maintaining it. Check out the wiki. http://fedoraproject.org/wiki/Extras should answer your questions. -- Aaron Kurtz From a.kurtz at hardsun.net Sat Apr 23 21:26:33 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Sat, 23 Apr 2005 14:26:33 -0700 Subject: request for review: tre In-Reply-To: References: Message-ID: <1114291593.30784.22.camel@rydia.hardsun.net> On Sat, 2005-04-23 at 07:21 -0400, Chris Ricker wrote: > > > tre is primarily a POSIX-compliant regexp library, but with support for > arbitrarily approximate matching. The package also includes agrep, a fuzzy > grep built using this library. > > Anyone care to review / sponsor? rpmlint says W: tre summary-not-capitalized lightweight POSIX-compliant regexp library Is this an important style point here? E: tre non-versioned-file-in-library-package /usr/share/man various complaints about this for various files, which will make it impossible to have multiple versions installed at once, but this doesn't seem to truly matter. E: tre standard-dir-owned-by-package /usr/share/man E: tre standard-dir-owned-by-package /usr/share/man/man1 This on the other hand should be fixed. %{_datadir}/* is causing it, and you don't want to do this. For one thing, both tre and tre-agrep own /usr/share/man/man1/agrep.1.gz W: tre one-line-command-in-%post /sbin/ldconfig W: tre one-line-command-in-%postun /sbin/ldconfig http://fedoraproject.org/wiki/ScriptletSnippets suggests but doesn't require doing this as %post -p /sbin/ldconfig and so. -- Aaron Kurtz From ivazquez at ivazquez.net Sat Apr 23 21:45:53 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 23 Apr 2005 17:45:53 -0400 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <1114265586.30340.18.camel@fc4t2.mpeters.local> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> <1114265586.30340.18.camel@fc4t2.mpeters.local> Message-ID: <1114292753.7784.34.camel@ignacio.ignacio.lan> On Sat, 2005-04-23 at 07:13 -0700, Michael A. Peters wrote: > http://mpeters.us/fc_extras/gourmet.spec > cd i18n > rm -f `find . -print |grep "\.mo$"` > chmod +x make_mo.sh > for a in *.po; do > file="`echo $a |sed s?"\.po$"?""?`" > ./make_mo.sh $file > done > cd .. pushd i18n find -name \*.mo | xargs rm -f # or find -name \*.mo -exec rm -f {} \; for file in *.po ; do sh make_mo.sh $(basename $file .po) done popd Although the apps build script really ought to be doing this itself. > %ghost %{_datadir}/applications/gourmet.desktop %ghost is usually used for files that will be created after RPM installation but need to be erased when the package is removed. This file really ought to just be rm'ed, or pass it to d-f-i along with --delete-original. -- 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 Sat Apr 23 22:00:44 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 23 Apr 2005 18:00:44 -0400 Subject: Review Request: NCO and CDO In-Reply-To: <1114269014.3297.167.camel@localhost.localdomain> References: <1113839355.16955.273.camel@ernie> <1114180831.27414.140.camel@ernie> <1114269014.3297.167.camel@localhost.localdomain> Message-ID: <1114293644.17203.78.camel@ernie> On Sat, 2005-04-23 at 10:10 -0500, Tom 'spot' Callaway wrote: > > You also need to apply one more package for udunits to work properly. > This patch is attached to the email. Hi Tom, Thank you for the feedback! I've incorporated all your fixes into the NCO and CDO packages. And I confirmed that NCO builds with udunits and opendap support in conjunction with your RPMs. So we're getting closer! The updated versions are available at: NCO: http://mitgcm.org/eh3/fedora_misc/nco.spec http://mitgcm.org/eh3/fedora_misc/cdo-0.9.6-2.src.rpm CDO: http://mitgcm.org/eh3/fedora_misc/cdo.spec http://mitgcm.org/eh3/fedora_misc/nco-3.0.0-2.src.rpm 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 -------------- 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 Apr 23 22:23:30 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 17:23:30 -0500 Subject: Sponsor and review request: opendap, librx In-Reply-To: <1114282186.17203.60.camel@ernie> References: <1114268730.3297.161.camel@localhost.localdomain> <1114282186.17203.60.camel@ernie> Message-ID: <1114295010.18906.13.camel@localhost.localdomain> On Sat, 2005-04-23 at 14:49 -0400, Ed Hill wrote: > In terms of both policy and practical considerations, is it OK to allow > packages (like OPeNDAP) to include their own versions of some libs? Or > should we patch their build system(s) to use the versions provided by > the "official" RPMs? No, it really isn't. This is how known security holes stick around for long periods of time after the core libs have been patched (like openssl in KDE). This should be policy, and I'll add it to the guidelines. I'm reworking opendap to use the system libs (new packages shortly). ~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 Sat Apr 23 22:31:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 17:31:23 -0500 Subject: Sponsor and review request: opendap, librx In-Reply-To: <20050423212932.26bcae86.bugs.michael@gmx.net> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> Message-ID: <1114295484.18906.16.camel@localhost.localdomain> On Sat, 2005-04-23 at 21:29 +0200, Michael Schwendt wrote: > Please double-check whether this should be > > BuildRequires: openssl-devel curl-devel pkgconfig Yeah, it should be. (with krb5-libs too) > > %install > > rm -rf ${RPM_BUILD_ROOT} > > cd DODS/ > > # move the docs to the toplevel > > mv ChangeLog INSTALL NEWS VERSION README ../ > > Not a blocker, since you're going to maintain this. But *please* try > not to break --short-circuit rpmbuild installs as they are really very > useful for debugging %install/%files sections. As a rule of thumb, > don't move/delete files below $RPM_BUILD_DIR. Where needed, copy > files to temporary directories. But don't delete or move them. I did this to make the copying easier (since this application set doesn't have any concept of "make install"), but now that I'm cutting out all the "included" packages that it was using (its own copy of zlib, curl, libxml2), its as easy (easier even) to not do it like this. > > %post devel > > /sbin/ldconfig > > > > %postun devel > > /sbin/ldconfig > > Missing dependencies on /sbin/ldconfig then, which is unlikely to not > be installed already. But well... Good point. I'll -p those. New opendap packages (much smaller, much faster to build) which incorporate all of Ed's and Michael's suggestions: SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-2.src.rpm Please sponsor or point out blockers. :) Thanks, ~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 Sat Apr 23 22:36:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 17:36:16 -0500 Subject: Review Request: NCO and CDO In-Reply-To: <1114293644.17203.78.camel@ernie> References: <1113839355.16955.273.camel@ernie> <1114180831.27414.140.camel@ernie> <1114269014.3297.167.camel@localhost.localdomain> <1114293644.17203.78.camel@ernie> Message-ID: <1114295776.18906.18.camel@localhost.localdomain> On Sat, 2005-04-23 at 18:00 -0400, Ed Hill wrote: > On Sat, 2005-04-23 at 10:10 -0500, Tom 'spot' Callaway wrote: > > > > You also need to apply one more package for udunits to work properly. > > This patch is attached to the email. > > Hi Tom, > > Thank you for the feedback! I've incorporated all your fixes into the > NCO and CDO packages. And I confirmed that NCO builds with udunits and > opendap support in conjunction with your RPMs. So we're getting closer! I'll sponsor NCO and CDO (NCO is contingent on opendap's sponsorship, due to BuildRequires). Good job Ed. ~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 ivazquez at ivazquez.net Sat Apr 23 21:28:33 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 23 Apr 2005 17:28:33 -0400 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <20050423212059.11deb9da.bugs.michael@gmx.net> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> Message-ID: <1114291713.7784.22.camel@ignacio.ignacio.lan> On Sat, 2005-04-23 at 21:20 +0200, Michael Schwendt wrote: > A few additional comments on SQLite v2 versus v3: > > * SQLite v3 file format is incompatible with v2. > Databases need to be converted with sqlite utility. Good to know. Does it warrant adding a note in either of the packages? > And with regard to any plans on upgrading the FC-3 branch, comments > on sqlite v2 dependencies: > > * Package "kannel": not built for FC3 > > * Package "moodss": current FC3 binaries not built with sqlite-tcl These should be modified to use sqlite2 I'm thinking. > * Package "php-pecl-sqlite": built with internal sqlite 2.8.14 A good reason to have some sort of 2.8.x version around externally. > * Package "python-sqlite" in FC-3 branch: no deps which use it And here's where I'm stumped. It's certainly possible to create a python-sqlite2 package, but parallel install will be broken. Or it could be patched to have a different module name, but that breaks Python programs that use it. Of course, once sqlite2 comes in this package won't be an upgrade blocker for anything in Core or Extras 4, so I'm wondering if anything should be done at all about it. Shall I go ahead and import sqlite2 then? -- 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 mpeters at mac.com Sat Apr 23 23:02:20 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 16:02:20 -0700 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <1114292753.7784.34.camel@ignacio.ignacio.lan> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> <1114265586.30340.18.camel@fc4t2.mpeters.local> <1114292753.7784.34.camel@ignacio.ignacio.lan> Message-ID: <1114297340.2732.4.camel@fc4t2.mpeters.local> On Sat, 2005-04-23 at 17:45 -0400, Ignacio Vazquez-Abrams wrote: > > > %ghost %{_datadir}/applications/gourmet.desktop > > %ghost is usually used for files that will be created after RPM > installation but need to be erased when the package is removed. OK. I thought it was for marking files in the buildroot that the rpm wasn't suppose to package. From ivazquez at ivazquez.net Sat Apr 23 23:15:07 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 23 Apr 2005 19:15:07 -0400 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <1114265586.30340.18.camel@fc4t2.mpeters.local> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> <1114265586.30340.18.camel@fc4t2.mpeters.local> Message-ID: <1114298107.7784.36.camel@ignacio.ignacio.lan> On Sat, 2005-04-23 at 07:13 -0700, Michael A. Peters wrote: > http://mpeters.us/fc_extras/gourmet.spec Something else I forgot to mention... Your call to d-f-i uses %buildroot, but the rest of the spec file uses $RPM_BUILD_ROOT. -- 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 wtogami at redhat.com Sat Apr 23 23:16:02 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 23 Apr 2005 13:16:02 -1000 Subject: Reminder: Account Sponsorship and New Members Message-ID: <426AD732.6090104@redhat.com> This is an important reminder for both Account Sponsors and New Members Sponsors ======== By sponsoring a new member, you are responsible for educating that developer and making sure they do the right thing. This means watching mailing lists and CVS commits list for their activity, and helping them out in their understanding of the process and packaging standards. Please do not approve too many new members that you are unable to keep track of their activities and foster their education, because it then becomes a burden on everyone else. New Members =========== http://www.redhat.com/mailman/listinfo/fedora-extras-list http://www.redhat.com/mailman/listinfo/fedora-extras-commits All contributors to CVS Extras are expected to be subscribed to minimally these two lists. You will miss vital package review comments if you do not follow these lists. You may filter extras-commits list to see only messages with your package somewhere in the subject if you wish to receive less mail. When posting to a list about any package, please include the package name somewhere within the Subject. This makes it much easier for everyone to search for all relevant messages relating to a certain package. Thank you for your attention to detail Warren Togami wtogami at redhat.com From mpeters at mac.com Sun Apr 24 00:08:00 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 23 Apr 2005 17:08:00 -0700 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <1114292753.7784.34.camel@ignacio.ignacio.lan> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> <1114265586.30340.18.camel@fc4t2.mpeters.local> <1114292753.7784.34.camel@ignacio.ignacio.lan> Message-ID: <1114301280.5051.4.camel@fc4t2.mpeters.local> On Sat, 2005-04-23 at 17:45 -0400, Ignacio Vazquez-Abrams wrote: > > pushd i18n > find -name \*.mo | xargs rm -f # or find -name \*.mo -exec rm -f {} \; > for file in *.po ; do > sh make_mo.sh $(basename $file .po) > done > popd > > Although the apps build script really ought to be doing this itself. Fixed. The apps build script doesn't do it, instead he provides the .mo files in the src tarball. > > %ghost is usually used for files that will be created after RPM > installation but need to be erased when the package is removed. This > file really ought to just be rm'ed, or pass it to d-f-i along with > --delete-original. fixed -=- (from other message) > Your call to d-f-i uses %buildroot, but the rest of the spec file uses > $RPM_BUILD_ROOT. fixed (I prefer %buildroot, easier to type - I had just left the $RPM_BUILD_ROOT in from the template) http://mpeters.us/fc_extras/gourmet.spec http://mpeters.us/fc_extras/gourmet-0.8.3.4-1.1.src.rpm From toshio at tiki-lounge.com Sun Apr 24 00:18:49 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 23 Apr 2005 17:18:49 -0700 Subject: request for review: xdaliclock In-Reply-To: <1114289564.30784.6.camel@rydia.hardsun.net>; from a.kurtz@hardsun.net on Sat, Apr 23, 2005 at 01:52:44PM -0700 References: <1114289564.30784.6.camel@rydia.hardsun.net> Message-ID: <20050423171849.A8593@tiki-lounge.com> On Sat, Apr 23, 2005 at 01:52:44PM -0700, Aaron Kurtz wrote: > On Sat, 2005-04-23 at 08:29 -0400, Chris Ricker wrote: > >Source0: http://www.jwz.org/xdaliclock/xdaliclock-%{version}.tar.gz > Isn't the convention to have the source not use macros? > No. Macros are fine. -Toshio From toshio at tiki-lounge.com Sun Apr 24 00:41:39 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 23 Apr 2005 17:41:39 -0700 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <1114297340.2732.4.camel@fc4t2.mpeters.local>; from mpeters@mac.com on Sat, Apr 23, 2005 at 04:02:20PM -0700 References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> <1114265586.30340.18.camel@fc4t2.mpeters.local> <1114292753.7784.34.camel@ignacio.ignacio.lan> <1114297340.2732.4.camel@fc4t2.mpeters.local> Message-ID: <20050423174139.B8593@tiki-lounge.com> On Sat, Apr 23, 2005 at 04:02:20PM -0700, Michael A. Peters wrote: > On Sat, 2005-04-23 at 17:45 -0400, Ignacio Vazquez-Abrams wrote: > > > > > > %ghost %{_datadir}/applications/gourmet.desktop > > > > %ghost is usually used for files that will be created after RPM > > installation but need to be erased when the package is removed. > > OK. I thought it was for marking files in the buildroot that the rpm > wasn't suppose to package. > That's %exclude. And according to this RedHat page, there's a preference to delete in the %install than to %exclude in %files:: http://www.fedora.redhat.com/participate/developers-guide/s1-rpm-more-guidelines.html -Toshio From denis at poolshark.org Sun Apr 24 00:51:04 2005 From: denis at poolshark.org (Denis Leroy) Date: Sat, 23 Apr 2005 17:51:04 -0700 Subject: Reminder: Account Sponsorship and New Members In-Reply-To: <426AD732.6090104@redhat.com> References: <426AD732.6090104@redhat.com> Message-ID: <426AED78.6030404@poolshark.org> Warren Togami wrote: > This is an important reminder for both Account Sponsors and New Members > > Sponsors > ======== > By sponsoring a new member, you are responsible for educating that > developer and making sure they do the right thing. This means > watching mailing lists and CVS commits list for their activity, and > helping them out in their understanding of the process and packaging > standards. Please do not approve too many new members that you are > unable to keep track of their activities and foster their education, > because it then becomes a burden on everyone else. > > New Members > =========== > http://www.redhat.com/mailman/listinfo/fedora-extras-list > http://www.redhat.com/mailman/listinfo/fedora-extras-commits > All contributors to CVS Extras are expected to be subscribed to > minimally these two lists. You will miss vital package review > comments if you do not follow these lists. You may filter > extras-commits list to see only messages with your package somewhere > in the subject if you wish to receive less mail. > > When posting to a list about any package, please include the package > name somewhere within the Subject. This makes it much easier for > everyone to search for all relevant messages relating to a certain > package. > > Thank you for your attention to detail > > Warren Togami > wtogami at redhat.com > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list Any word on when the CVS access page fill be fixed ? I've been trying to add myself to the 'cvsextras' group for a while, but I keep getting an 'Attribute Error' Python error page... -denis From a.kurtz at hardsun.net Sun Apr 24 01:24:13 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Sat, 23 Apr 2005 18:24:13 -0700 Subject: request for review: xdaliclock In-Reply-To: <20050423171849.A8593@tiki-lounge.com> References: <1114289564.30784.6.camel@rydia.hardsun.net> <20050423171849.A8593@tiki-lounge.com> Message-ID: <1114305853.30784.25.camel@rydia.hardsun.net> On Sat, 2005-04-23 at 17:18 -0700, Toshio Kuratomi wrote: > On Sat, Apr 23, 2005 at 01:52:44PM -0700, Aaron Kurtz wrote: > > On Sat, 2005-04-23 at 08:29 -0400, Chris Ricker wrote: > > >Source0: http://www.jwz.org/xdaliclock/xdaliclock-%{version}.tar.gz > > Isn't the convention to have the source not use macros? > > > No. Macros are fine. http://fedoraproject.org/wiki/PackagingGuidelines#head-899bd694d29ace1be956ab35177075021977560b should be altered to note this then. -- Aaron Kurtz From bugs.michael at gmx.net Sun Apr 24 09:06:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Apr 2005 11:06:59 +0200 Subject: Sponsor and review request: opendap, librx In-Reply-To: <1114295484.18906.16.camel@localhost.localdomain> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> Message-ID: <20050424110659.6c85849c.bugs.michael@gmx.net> On Sat, 23 Apr 2005 17:31:23 -0500, Tom 'spot' Callaway wrote: > On Sat, 2005-04-23 at 21:29 +0200, Michael Schwendt wrote: > > > Please double-check whether this should be > > > > BuildRequires: openssl-devel curl-devel pkgconfig > > Yeah, it should be. (with krb5-libs too) openssl-devel requires krb5-devel which in turn requires krb5-libs > New opendap packages (much smaller, much faster to build) which > incorporate all of Ed's and Michael's suggestions: > SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec > SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-2.src.rpm > > Please sponsor or point out blockers. :) These packages can be pushed through by Ed and you as a team. I don't sponsor a package based on just skimming over a spec file. ;) From ivazquez at ivazquez.net Sun Apr 24 09:40:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 24 Apr 2005 05:40:25 -0400 Subject: Request for sponsor: OpenEXR, swish-e Message-ID: <1114335625.7784.41.camel@ignacio.ignacio.lan> OpenEXR: A high dynamic-range (HDR) image file format OpenEXR is a high dynamic-range (HDR) image file format developed by Industrial Light & Magic for use in computer imaging applications. This package contains libraries and sample applications for handling the format. http://fedora.ivazquez.net/files/OpenEXR-1.2.2-1.src.rpm swish-e: Simple Web Indexing System for Humans - Enhanced Swish-e is Simple Web Indexing System for Humans - Enhanced. Swish-e can quickly and easily index directories of files or remote web sites and search the generated indexes. http://fedora.ivazquez.net/files/swish-e-2.4.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 ivazquez at ivazquez.net Sun Apr 24 09:40:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 24 Apr 2005 05:40:27 -0400 Subject: Review needed: gnet2 Message-ID: <1114335627.7784.42.camel@ignacio.ignacio.lan> gnet2: A simple network library built upon glib GNet is a simple network library. It is written in C, object-oriented, and built upon GLib. It is intended to be easy to use and port. -- 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 Sun Apr 24 09:49:13 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Apr 2005 11:49:13 +0200 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <1114291713.7784.22.camel@ignacio.ignacio.lan> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> <1114291713.7784.22.camel@ignacio.ignacio.lan> Message-ID: <20050424114913.1c723503.bugs.michael@gmx.net> On Sat, 23 Apr 2005 17:28:33 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-04-23 at 21:20 +0200, Michael Schwendt wrote: > > A few additional comments on SQLite v2 versus v3: > > > > * SQLite v3 file format is incompatible with v2. > > Databases need to be converted with sqlite utility. > > Good to know. Does it warrant adding a note in either of the packages? It's something which needs to be addressed for any package, which created sqlite v2 databases in the past and is built against sqlite v3 later. It could be feasible to dump and rebuild databases on-the-fly in package upgrade scriptlets. I think that's something the package maintainers need to consider. > > And with regard to any plans on upgrading the FC-3 branch, comments > > on sqlite v2 dependencies: > > > > * Package "kannel": not built for FC3 > > > > * Package "moodss": current FC3 binaries not built with sqlite-tcl > > These should be modified to use sqlite2 I'm thinking. For "kannel" it's trivial, since the sqlite2 package only renames the package and doesn't introduce any important changes. But I leave the decision of what to do with kannel to its package owner: Matthias > > * Package "php-pecl-sqlite": built with internal sqlite 2.8.14 > > A good reason to have some sort of 2.8.x version around externally. Yes, it ought to be built with the external sqlite. > > * Package "python-sqlite" in FC-3 branch: no deps which use it > > And here's where I'm stumped. It's certainly possible to create a > python-sqlite2 package, but parallel install will be broken. Or it could > be patched to have a different module name, but that breaks Python > programs that use it. > > Of course, once sqlite2 comes in this package won't be an upgrade > blocker for anything in Core or Extras 4, so I'm wondering if anything > should be done at all about it. I haven't had a look at the python-sqlite API. Has it changed? Isn't it an upwards compatible API which separates Python programmers from the SQLite API? As I suggested before, we should let the FC-3 branch rest in peace unless we need more sqlite usage in there. For FE4 we don't need a python-sqlite2. Python packages should be able to use python-sqlite from FC4. > Shall I go ahead and import sqlite2 then? Fine with me in "devel" tree, but I don't maintain the three packages mentioned above. So, to demonstrate that coordination among packagers works, how about the package owners give their explicit "okay" at this point? From jfontain at free.fr Sun Apr 24 10:03:07 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 24 Apr 2005 12:03:07 +0200 Subject: Review/sponsor needed: sqlite2 In-Reply-To: <20050424114913.1c723503.bugs.michael@gmx.net> References: <1114241243.7784.17.camel@ignacio.ignacio.lan> <20050423212059.11deb9da.bugs.michael@gmx.net> <1114291713.7784.22.camel@ignacio.ignacio.lan> <20050424114913.1c723503.bugs.michael@gmx.net> Message-ID: <426B6EDB.3050506@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: >> Shall I go ahead and import sqlite2 then? > > > Fine with me in "devel" tree, but I don't maintain the three > packages mentioned above. So, to demonstrate that coordination > among packagers works, how about the package owners give their > explicit "okay" at this point? I don't know if you mean me, but as far as moodss goes, it is OK with me. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCa27bkG/MMvcT1qQRAmHZAJsEfLThuODagdRM/d8dtKe2u1VEAACglhQ1 itHLAK7gvvqxOuXdBYmsdRs= =n0bx -----END PGP SIGNATURE----- From i at stingr.net Sun Apr 24 10:07:20 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Sun, 24 Apr 2005 14:07:20 +0400 Subject: sponsor and review request: rzip Message-ID: <20050424100720.GE11570@stingr.stingr.net> rzip is a compression program written by Andrew Tridgell. More information is available at http://rzip.samba.org/ SRPM available at http://gw6.sgu.ru/st/SRPMS/rzip-2.0-1.src.rpm -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From adrian at lisas.de Sun Apr 24 10:34:48 2005 From: adrian at lisas.de (Adrian Reber) Date: Sun, 24 Apr 2005 12:34:48 +0200 Subject: sponsor and review request: rzip In-Reply-To: <20050424100720.GE11570@stingr.stingr.net> References: <20050424100720.GE11570@stingr.stingr.net> Message-ID: <20050424103448.GA25200@lisas.de> On Sun, Apr 24, 2005 at 02:07:20PM +0400, Paul P Komkoff Jr wrote: > rzip is a compression program written by Andrew Tridgell. > More information is available at http://rzip.samba.org/ > SRPM available at http://gw6.sgu.ru/st/SRPMS/rzip-2.0-1.src.rpm You shouldn't specify $RPM_BUILD_ROOT during %build. Although the path doesn't seem to be anywhere in the built package following patch should be applied: --- rzip.spec 2005-04-24 11:17:49.000000000 +0200 +++ /tmp/rzip.spec 2005-04-24 12:25:56.000000000 +0200 @@ -20,13 +20,13 @@ %build -%configure --prefix=$RPM_BUILD_ROOT/usr/share --exec-prefix=$RPM_BUILD_ROOT/usr +%configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT -make install +make install INSTALL_BIN=$RPM_BUILD_ROOT%{_bindir} INSTALL_MAN=$RPM_BUILD_ROOT%{_mandir} %clean Maybe you could also change the summary from: Summary: A tridge file compression utility to the one specified in the man page: Summary: A large-file compression program And a %doc section would be nice even if it only includes the COPYING file. Adrian From mattdm at mattdm.org Sun Apr 24 14:04:57 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 24 Apr 2005 10:04:57 -0400 Subject: Request for review: python-ZSI, python-SOAPpy, python-fpconst In-Reply-To: <20050419151811.GA28997@jadzia.bu.edu> References: <20050418140154.GB20034@jadzia.bu.edu> <1113848032.26306.19.camel@ignacio.ignacio.lan> <20050419151811.GA28997@jadzia.bu.edu> Message-ID: <20050424140457.GA2132@jadzia.bu.edu> On Tue, Apr 19, 2005 at 11:18:11AM -0400, Matthew Miller wrote: > Updated packages and spec files at: > Okay, so what happens now? Should I import these into CVS? Do I need someone to say "I sponsor these?" before that? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From i at stingr.net Sun Apr 24 15:03:22 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Sun, 24 Apr 2005 19:03:22 +0400 Subject: sponsor and review request: rzip In-Reply-To: <20050424103448.GA25200@lisas.de> References: <20050424100720.GE11570@stingr.stingr.net> <20050424103448.GA25200@lisas.de> Message-ID: <20050424150322.GG11570@stingr.stingr.net> Replying to Adrian Reber: > You shouldn't specify $RPM_BUILD_ROOT during %build. Although the path > doesn't seem to be anywhere in the built package following patch > should be applied: Done. Updated SRPM at the same location http://gw6.sgu.ru/st/SRPMS/rzip-2.0-1.src.rpm -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From Jochen at herr-schmitt.de Sun Apr 24 18:47:37 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 24 Apr 2005 20:47:37 +0200 Subject: Rebuild of inadyn required Message-ID: Hello, I have a little problem and hope anyone can help me. I have created the inadyn package, which was inported in the CVS. I have edit the Extras/FC3Status end Extras/FC4Status page to request a build of the package. Unfortunately, until now, I couldn't found any information about a built of the requested package. It will be nice, if anyone can guide me, becouse I assume, that I have forget anything which is require to trigger the build process. Best Regards: Jochen Schmitt From bdpepple at ameritech.net Sun Apr 24 19:21:46 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 24 Apr 2005 15:21:46 -0400 Subject: Rebuild of inadyn required In-Reply-To: References: Message-ID: <1114370506.7060.2.camel@localhost.localdomain> On Sun, 2005-04-24 at 20:47 +0200, Jochen Schmitt wrote: > Hello, > > I have a little problem and hope anyone can help me. > > I have created the inadyn package, which was inported in the CVS. > > I have edit the Extras/FC3Status end Extras/FC4Status page to > request a build of the package. Looks like it was removed from the FC4 Status page before a built was done. Here's the diff: * inadyn (i386, x86_65, ppc) (warren: What the heck is this? It isn't in CVS, no approval message, etc.) /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 Jochen at herr-schmitt.de Sun Apr 24 20:12:54 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 24 Apr 2005 22:12:54 +0200 Subject: Rebuild of inadyn required In-Reply-To: <1114370506.7060.2.camel@localhost.localdomain> References: <1114370506.7060.2.camel@localhost.localdomain> Message-ID: <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> On Sun, 24 Apr 2005 15:21:46 -0400, you wrote: >* inadyn (i386, x86_65, ppc) (warren: What the heck is this? It isn't in >CVS, no approval message, etc.) Sorry, I didn't sent a approval message, becouse I thought, that only CVS will sent messages to fedora-extras-commits during a checkin process. After a watch on the archiv, I assume, that the owner of a package have to sent the approval message to the list independent from the CVS checkin process. I have sent now a message to this list. As sencond I have verified that /cvs/extras/devel/inadyn exists since 11 days in the CVS. Please see: http://cvs.fedora.redhat.com/viewcvs/devel/inadyn/?root=extras I will now edit the pages again and hope my best. Best Regards: Jochen Schmitt From malists at epon.ro Sun Apr 24 20:37:58 2005 From: malists at epon.ro (Marius Andreiana) Date: Sun, 24 Apr 2005 23:37:58 +0300 Subject: more games Message-ID: <1114375078.5382.10.camel@marte.biciclete.ro> Hi, I downloaded Wesnoth from fedora extras and I was impressed by it's quality (both action and graphics). Other nice games which would be a good addition to development extras: Pachi el martiano http://dragontech.sourceforge.net/index.php?main=pachi&lang=en Martian memory http://dragontech.sourceforge.net/index.php?main=martian&lang=en LGeneral and other L* games http://lgames.sourceforge.net/index.php?project=LGeneral Pingus http://pingus.seul.org/welcome.html Thanks, -- Marius Andreiana From bugs.michael at gmx.net Sun Apr 24 20:43:05 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Apr 2005 22:43:05 +0200 Subject: Rebuild of inadyn required In-Reply-To: <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> Message-ID: <20050424224305.459ef0b5.bugs.michael@gmx.net> On Sun, 24 Apr 2005 22:12:54 +0200, Jochen Schmitt wrote: > On Sun, 24 Apr 2005 15:21:46 -0400, you wrote: > > >* inadyn (i386, x86_65, ppc) (warren: What the heck is this? It isn't in > >CVS, no approval message, etc.) > > Sorry, I didn't sent a approval message, becouse I thought, that > only CVS will sent messages to fedora-extras-commits during a > checkin process. > > After a watch on the archiv, I assume, that the owner of a > package have to sent the approval message to the list independent > from the CVS checkin process. I have sent now a message to this > list. > > As sencond I have verified that /cvs/extras/devel/inadyn exists > since 11 days in the CVS. Please see: > > http://cvs.fedora.redhat.com/viewcvs/devel/inadyn/?root=extras > > I will now edit the pages again and hope my best. The package exists only in the "devel" tree, not in the FC-3 branch. You edited the FC3Status page to request a build for FC3, which won't work because an "inadyn" module does not exist in FC-3 branch of Fedora Extras CVS. To request creation of a module in that branch, you need to edit the CVSSyncNeeded page (name of the page has historic reasons ;). From mattdm at mattdm.org Sun Apr 24 21:06:25 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 24 Apr 2005 17:06:25 -0400 Subject: more games In-Reply-To: <1114375078.5382.10.camel@marte.biciclete.ro> References: <1114375078.5382.10.camel@marte.biciclete.ro> Message-ID: <20050424210625.GA12989@jadzia.bu.edu> On Sun, Apr 24, 2005 at 11:37:58PM +0300, Marius Andreiana wrote: > I downloaded Wesnoth from fedora extras and I was impressed by it's > quality (both action and graphics). Other nice games which would be a > good addition to development extras: Sounds great. Package 'em up! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From ed at eh3.com Mon Apr 25 00:26:25 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 24 Apr 2005 20:26:25 -0400 Subject: Sponsor and review request: opendap, librx In-Reply-To: <20050424110659.6c85849c.bugs.michael@gmx.net> References: <1114268730.3297.161.camel@localhost.localdomain> <20050423212932.26bcae86.bugs.michael@gmx.net> <1114295484.18906.16.camel@localhost.localdomain> <20050424110659.6c85849c.bugs.michael@gmx.net> Message-ID: <1114388785.30690.2.camel@ernie> On Sun, 2005-04-24 at 11:06 +0200, Michael Schwendt wrote: > On Sat, 23 Apr 2005 17:31:23 -0500, Tom 'spot' Callaway wrote: > > New opendap packages (much smaller, much faster to build) which > > incorporate all of Ed's and Michael's suggestions: > > SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec > > SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-2.src.rpm > > > > Please sponsor or point out blockers. :) > > These packages can be pushed through by Ed and you as a team. I don't > sponsor a package based on just skimming over a spec file. ;) Hi Tom, The opendap package built and I installed the three resulting binary RPMs. Skimming [:-)] over the spec file and the list of installed files, it appears there are no shared libraries. So is it OK to remove the %post/%postun bits? Or did I miss something? Also, I tried to run the "dncview" program on a few small netCDF files and it seg-faulted. It seg-faulted on "dncview -h". And the older version (built from opendap-3.4.4-1 SRPM) also seg-faulted so its rather unlikely that any of your newer patches caused it. I'll look into it and try to figure out whats happening. 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 mpeters at mac.com Mon Apr 25 02:10:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 24 Apr 2005 19:10:14 -0700 Subject: gournet review (was Re: i18n guidelines?) In-Reply-To: <1114265586.30340.18.camel@fc4t2.mpeters.local> References: <1113702026.508.15.camel@fc4t2.mpeters.local> <20050417055650.A10311@tiki-lounge.com> <1114265586.30340.18.camel@fc4t2.mpeters.local> Message-ID: <1114395014.8390.9.camel@fc4t2.mpeters.local> I have made one final change to the spec file. Instead of patching the desktop file, I am doing it with sed in the % build section. The problems with the vendor desktop file: He uses a . at the end of description lines. I don't think that breaks any "rules" but other desktop files in fedora do not do this, so it is more consistent to remove those periods. And in one place he uses True for a boolean value, desktop-file-install prefers that be all lower case (true). Reason for doing it with sed instead of patch: The desktop file is currently changing, the developer is actively adding language support to the project, and thus is updating the desktop file. The addition of periods at the end of the language specific descriptions is predictable, sed will handle that just fine - generating a new desktop patch with every release that updates the file is more work. The current spec file and src.rpm: http://mpeters.us/fc_extras/gourmet.spec http://mpeters.us/fc_extras/gourmet-0.8.3.4-1.2.src.rpm From malists at epon.ro Mon Apr 25 05:07:05 2005 From: malists at epon.ro (Marius Andreiana) Date: Mon, 25 Apr 2005 08:07:05 +0300 Subject: more games In-Reply-To: <20050424210625.GA12989@jadzia.bu.edu> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> Message-ID: <1114405625.2993.2.camel@marte.biciclete.ro> On Sun, 2005-04-24 at 17:06 -0400, Matthew Miller wrote: > On Sun, Apr 24, 2005 at 11:37:58PM +0300, Marius Andreiana wrote: > > I downloaded Wesnoth from fedora extras and I was impressed by it's > > quality (both action and graphics). Other nice games which would be a > > good addition to development extras: > > Sounds great. Package 'em up! Ok, I'm sorry for suggesting those. I mistakenly thought people could also kindly ask for package packages here. -- Marius Andreiana From mpeters at mac.com Mon Apr 25 05:53:04 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 24 Apr 2005 22:53:04 -0700 Subject: more games In-Reply-To: <1114405625.2993.2.camel@marte.biciclete.ro> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> Message-ID: <1114408385.23816.12.camel@fc4t2.mpeters.local> On Mon, 2005-04-25 at 08:07 +0300, Marius Andreiana wrote: > On Sun, 2005-04-24 at 17:06 -0400, Matthew Miller wrote: > > On Sun, Apr 24, 2005 at 11:37:58PM +0300, Marius Andreiana wrote: > > > I downloaded Wesnoth from fedora extras and I was impressed by it's > > > quality (both action and graphics). Other nice games which would be a > > > good addition to development extras: > > > > Sounds great. Package 'em up! > Ok, I'm sorry for suggesting those. I mistakenly thought people could > also kindly ask for package packages here. > Is anyone working on a clanlib spec? I have a personal one that builds, though I suspect it probably needs to be broken up more (I just have clanlib clanlib-devel and clanlib-doc) and I haven't done anything with the BuildRequires. And some (at least one) of the configure switches needs to be ifarch'd if it was to be public. I don't want to maintain something that big though. But it would be useful for extras to have, a lot of games do use it, and games are good. maybe if you sent an e-mail to the clanlib list a developer there would be interested in maintaining an extras package? I suspect getting clanlib into extras is the key to getting more games submitted. Does clanlib have any patent issues? That's always the scary part about large projects. From mattdm at mattdm.org Mon Apr 25 12:22:26 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 08:22:26 -0400 Subject: more games In-Reply-To: <1114405625.2993.2.camel@marte.biciclete.ro> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> Message-ID: <20050425122226.GA2427@jadzia.bu.edu> On Mon, Apr 25, 2005 at 08:07:05AM +0300, Marius Andreiana wrote: > > > I downloaded Wesnoth from fedora extras and I was impressed by it's > > > quality (both action and graphics). Other nice games which would be a > > > good addition to development extras: > > Sounds great. Package 'em up! > Ok, I'm sorry for suggesting those. I mistakenly thought people could > also kindly ask for package packages here. Oh, feel free. It's just less likely to happen unless someone steps up and does it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 71 degrees Fahrenheit. From mattdm at mattdm.org Mon Apr 25 12:29:35 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 08:29:35 -0400 Subject: more games In-Reply-To: <1114408385.23816.12.camel@fc4t2.mpeters.local> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <1114408385.23816.12.camel@fc4t2.mpeters.local> Message-ID: <20050425122935.GB2427@jadzia.bu.edu> On Sun, Apr 24, 2005 at 10:53:04PM -0700, Michael A. Peters wrote: > Is anyone working on a clanlib spec? We have one here @ BU. (One of our goals is to merge all of this stuff into Fedora Extras, but we're crazy busy with internal work right now.) I'll stick it at the end of this message though, in case it helps. > I have a personal one that builds, though I suspect it probably needs to > be broken up more (I just have clanlib clanlib-devel and clanlib-doc) > and I haven't done anything with the BuildRequires. I don't see an advantage in breaking it up too much. Just adds confusion without much practical gain -- it's not like it's that huge of a package. We just have ClanLib and ClanLib-devel. (With most of the docs in -devel.) Also, needs some cleanup, and now that I look at it closely, not sure exactly why ExclusiveArch is in there.... So anyway: Summary: The ClanLib Game SDK Name: ClanLib Version: 0.7.8 Release: %{bu_tag}7 License: LGPL Group: System Environment/Libraries BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot Source: http://clanlib.org/~sphair/download/ClanLib-%{version}-1.tar.bz2 # not really based on this.... Source9999: clanlib.spec URL: http://clanlib.org/ BuildRequires: zlib-devel mikmod libpng-devel Mesa-devel vorbis-tools libvorbis-devel lua # whatever this is.... BuildConflicts: OpenPTC-devel ExclusiveArch: i386 i486 i586 i686 # subsume pointless subpackages: Provides: %{name}-gl %{name}-sound %{name}-network %{name}-vorbis %{name}-gui %{name}-mikmod %description The ClanLib Game SDK is a crossplatform game library designed to ease the work for game developers. The goal is to provide a common interface to classical game problems (loading graphics eg.), so games can share as much code as possible. Ideally anyone with small resources should be able to write commercial quality games. %package devel Summary: ClanLib include files and static libraries for developers Group: Development/Libraries Requires: ClanLib = %{version} %description devel The ClanLib Game SDK is a crossplatform game library designed to ease the work for game developers. This package contains the header files and development files needed to build ClanLib applications. If you're writing or compiling programs using ClanLib, you want this. If you're just installing binary game packages, you don't. %prep %setup -q # Some people use HORRIBLE editors!!! # Includes *MUST* end with a newline! # Fix this up for i in `find . -name "*.h" -type f`; do echo >>$i; done %build autoconf %configure --enable-dyn \ --enable-docs \ --enable-clanDisplay \ --enable-clanSDL \ --enable-clanGL \ --enable-clanSound \ --enable-clanNetwork \ --enable-clanGUI \ --enable-clanMikMod \ --enable-clanVorbis \ make %{?_smp_mflags} all %install %makeinstall BIN_PREFIX=$RPM_BUILD_ROOT%{_bindir} LIB_PREFIX=$RPM_BUILD_ROOT%{_libdir} INC_PREFIX=$RPM_BUILD_ROOT%{_includedir} TARGET_PREFIX=$RPM_BUILD_ROOT%{_libdir}/%{name} # clean up things that shouldn't be packaged find $RPM_BUILD_ROOT -type f -name "*.la" -exec rm -f {} ';' %post -p /sbin/ldconfig %postun -p /sbin/ldconfig %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-, root, root) %doc README COPYING CREDITS ascii-logo NEWS TODO-RSN %{_libdir}/*.so.* %files devel %defattr(-, root, root) %doc CODING_STYLE %doc %{_docdir}/clanlib/* %{_libdir}/*.a %{_libdir}/*.so %{_libdir}/pkgconfig/*.pc %{_includedir}/ClanLib-0.7/* %changelog * Tue Mar 22 2005 Jeffrey A. Rogers 0.7.8-bu45.7 - Changed build requires from vorbis to vorbis-tools * Fri Mar 18 2005 Jeffrey A. Rogers 0.7.8bu45.6 - Ported Bossanova's version into Velouria - Velourized the spec file * Wed Jun 02 2004 Matthew Miller - update to 0.7.8 for Bossanova final release - ooh, there's a new spec file in the tarball; syncing with that. - ooh, no, even better: - oh. those both aren't the best. well, taking the best of both of 'em. - getting rid of zillions of sub-packages. either you want ClanLib or you don't. The only sensible distinction is devel and plain. - this version no longer requires Hermes-devel * Thu Apr 15 2004 Joe Szep - rebuilt newer version for f2tc2 * Wed Apr 16 2003 Matthew Miller - rebuilt for doolittle - changed spec file name to StudlyCaps to match package name * Wed Jan 08 2003 Joe Szep - update for Doolittle - removed GL support as it doesn't even compile * Wed Jul 24 2002 Joe Szep - bug fixes * Mon Apr 29 2002 Joe Szep - new version, updated to Gigantic * Fri Nov 16 2001 Joe Szep - initial BU release; updated to rh 7.2 -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 71 degrees Fahrenheit. From mpeters at mac.com Mon Apr 25 12:55:12 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 25 Apr 2005 05:55:12 -0700 Subject: more games In-Reply-To: <20050425122935.GB2427@jadzia.bu.edu> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <1114408385.23816.12.camel@fc4t2.mpeters.local> <20050425122935.GB2427@jadzia.bu.edu> Message-ID: <1114433712.1438.3.camel@fc4t2.mpeters.local> On Mon, 2005-04-25 at 08:29 -0400, Matthew Miller wrote: > On Sun, Apr 24, 2005 at 10:53:04PM -0700, Michael A. Peters wrote: > > Is anyone working on a clanlib spec? > > We have one here @ BU. (One of our goals is to merge all of this stuff into > Fedora Extras, but we're crazy busy with internal work right now.) I'll > stick it at the end of this message though, in case it helps. > > > I have a personal one that builds, though I suspect it probably needs to > > be broken up more (I just have clanlib clanlib-devel and clanlib-doc) > > and I haven't done anything with the BuildRequires. > > I don't see an advantage in breaking it up too much. Just adds confusion > without much practical gain -- it's not like it's that huge of a package. I was thinking the advantage *might* be to lessen the dependencies. But :shrug: I do think the docs need to be separate though. If you just want the devel package in order to compile some game you downloaded, and not to do actual development, the docs really aren't needed. From mpeters at mac.com Mon Apr 25 12:59:29 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 25 Apr 2005 05:59:29 -0700 Subject: libvisual Message-ID: <1114433969.1438.8.camel@fc4t2.mpeters.local> I see that libvisual is in Extras - but I don't see any libvisual-plugins package. Is that a bug? the library is kind of useless without visualizaer plugins, or at least seems to me. I've only used libvisual with xmms and totem (via the libvisual gstreamer plugin). Do they not contain the libvisual name? [livna at fc4t2 ~]$ yum list |grep libvisual libvisual.i386 0.2.0-3 installed libvisual-devel.i386 0.2.0-3 installed [livna at fc4t2 ~]$ If need be I can provide a package for them. From mattdm at mattdm.org Mon Apr 25 13:34:26 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 09:34:26 -0400 Subject: more games In-Reply-To: <1114433712.1438.3.camel@fc4t2.mpeters.local> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <1114408385.23816.12.camel@fc4t2.mpeters.local> <20050425122935.GB2427@jadzia.bu.edu> <1114433712.1438.3.camel@fc4t2.mpeters.local> Message-ID: <20050425133426.GA4926@jadzia.bu.edu> On Mon, Apr 25, 2005 at 05:55:12AM -0700, Michael A. Peters wrote: > I was thinking the advantage *might* be to lessen the dependencies. > But :shrug: I don't see too many that wouldn't probably already be on a system where you'd be running games. Anything in particular you're thinking of? > I do think the docs need to be separate though. > If you just want the devel package in order to compile some game you > downloaded, and not to do actual development, the docs really aren't > needed. I guess they are a little big on disk. Although, there is "--excludedocs".... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 71 degrees Fahrenheit. From Jochen at herr-schmitt.de Mon Apr 25 13:46:00 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Apr 2005 15:46:00 +0200 Subject: Review Request: inadyn Message-ID: Hello, it will be nice, if anyone can review the package inadyn-1.90, which you may find at: http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Mon Apr 25 13:50:21 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Apr 2005 15:50:21 +0200 Subject: Review Request: inadyn In-Reply-To: References: Message-ID: On Mon, 25 Apr 2005 15:46:00 +0200, you wrote: >http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm Should be: >http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-4.src.rpm Sorry for any inconvinience. Best Regards: Jochen Schmitt From qspencer at ieee.org Mon Apr 25 14:42:29 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 09:42:29 -0500 Subject: Review Request: fftw3, cln, GiNaC In-Reply-To: <20050424224305.459ef0b5.bugs.michael@gmx.net> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> Message-ID: <426D01D5.6080605@ieee.org> Thanks to all who have already looked at these. I think I have resolved all outstanding problems and am requesting a new review. regards, Quentin From qspencer at ieee.org Mon Apr 25 14:50:26 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 09:50:26 -0500 Subject: Octave-forge and legal issues In-Reply-To: <20050424224305.459ef0b5.bugs.michael@gmx.net> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> Message-ID: <426D03B2.4030400@ieee.org> I have resolved most of the problems with octave-forge this package except one, and I don't know how best to proceed. Someone discovered something in the source tree that I had forgotten about: there is a nonfree source tree containing a few functions whose license prohibit commercial redistribution. The nonfree tree is not built into the resulting RPM, but the source would remain in the source tarball. I see the following options: 1. Ask the legal department if this is allowed and can stay as it is. 2. Create a modified source tarball with the offending code removed. This would be easy, but the source wouldn't match the upstream source. 3. Get the upstream maintainer to remove the offending source code (this has been discussed and he has expressed a willingness to do that, but I don't know how soon the next release will be, the current one is 6 months old). Right now, I'd like to go with option 2 because it's something I can do without waiting for anyone else. My question is, does this break any established rules or preferred ways of doing things? regards, Quentin From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 25 14:56:10 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Apr 2005 16:56:10 +0200 Subject: Octave-forge and legal issues In-Reply-To: <426D03B2.4030400@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> Message-ID: <20050425165610.3f8a12e0@python2> Quentin Spencer wrote : > 2. Create a modified source tarball with the offending code removed. > This would be easy, but the source wouldn't match the upstream source. This has already been done for some packages (e.g. xmms, gstreamer- plugins), and AFAIK is acceptable. Ideally, include as one of the "SourceX:" lines a quick little script that can reproduce the modified tarball from the original one (uncompress the original tarball, remove this and that, recompress with the new tarball name). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.13 1.01 0.86 From rc040203 at freenet.de Mon Apr 25 15:23:09 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 25 Apr 2005 17:23:09 +0200 Subject: Octave-forge and legal issues In-Reply-To: <20050425165610.3f8a12e0@python2> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> Message-ID: <1114442589.7227.121.camel@mccallum.corsepiu.local> On Mon, 2005-04-25 at 16:56 +0200, Matthias Saou wrote: > Quentin Spencer wrote : > > > 2. Create a modified source tarball with the offending code removed. > > This would be easy, but the source wouldn't match the upstream source. > > This has already been done for some packages (e.g. xmms, gstreamer- > plugins), and AFAIK is acceptable. ... unless the sources are GPL'ed. Not shipping the original sources would violate the GPL. octave-forge's spec claims the package to be gpl'ed, but a closer look reveals it not be entirely GPL'ed, but to be a collection of sources carrying different licenses. So, removing the offending sources legally probably would be OK. Ralf From fedora-lists at rewster.org Mon Apr 25 15:28:08 2005 From: fedora-lists at rewster.org (fedora-lists at rewster.org) Date: Mon, 25 Apr 2005 11:28:08 -0400 (EDT) Subject: more games (plus crack-attack) In-Reply-To: <20050425122226.GA2427@jadzia.bu.edu> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> Message-ID: On Mon, 25 Apr 2005, Matthew Miller wrote: > On Mon, Apr 25, 2005 at 08:07:05AM +0300, Marius Andreiana wrote: >>>> I downloaded Wesnoth from fedora extras and I was impressed by it's >>>> quality (both action and graphics). Other nice games which would be a >>>> good addition to development extras: >>> Sounds great. Package 'em up! >> Ok, I'm sorry for suggesting those. I mistakenly thought people could >> also kindly ask for package packages here. > > Oh, feel free. It's just less likely to happen unless someone steps up and > does it. > I'd be willing to take a look at Pingus (and pitch in with the clanlib dependency). I'd say I'd look at the other packages too but I'm still trying to get my footing in this whole packaging thing, don't wanna take on too much too soon ;) Also, I have a spec file just about finished for crack-attack (which looks like it's been forked from the old version at aluminumangel, http://savannah.nongnu.org/projects/crack-attack) I'll post my specfile (for c-a) later this evening after doing a few last embarassment checks. -- JP LaFleur fedora-lists at rewster.org From qspencer at ieee.org Mon Apr 25 15:28:29 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 10:28:29 -0500 Subject: Octave-forge and legal issues In-Reply-To: <1114442589.7227.121.camel@mccallum.corsepiu.local> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> Message-ID: <426D0C9D.5060204@ieee.org> Ralf Corsepius wrote: >On Mon, 2005-04-25 at 16:56 +0200, Matthias Saou wrote: > > >>Quentin Spencer wrote : >> >> >>>2. Create a modified source tarball with the offending code removed. >>>This would be easy, but the source wouldn't match the upstream source. >>> >>> >>This has already been done for some packages (e.g. xmms, gstreamer- >>plugins), and AFAIK is acceptable. >> >> >... unless the sources are GPL'ed. Not shipping the original sources >would violate the GPL. > >octave-forge's spec claims the package to be gpl'ed, but a closer look >reveals it not be entirely GPL'ed, but to be a collection of sources >carrying different licenses. > >So, removing the offending sources legally probably would be OK. > > Yes, I erroneously assumed that it was GPL. Many of the functions are GPL, but not all, and the license distributed with the sources in fact says the collection is licensed as public domain. The updated spec file now shows this, and I'll soon create a modified tarball that should remove all incompatible source files. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 25 15:35:10 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Apr 2005 17:35:10 +0200 Subject: Octave-forge and legal issues In-Reply-To: <1114442589.7227.121.camel@mccallum.corsepiu.local> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> Message-ID: <20050425173510.3f88164d@python2> Ralf Corsepius wrote : > On Mon, 2005-04-25 at 16:56 +0200, Matthias Saou wrote: > > Quentin Spencer wrote : > > > > > 2. Create a modified source tarball with the offending code removed. > > > This would be easy, but the source wouldn't match the upstream source. > > > > This has already been done for some packages (e.g. xmms, gstreamer- > > plugins), and AFAIK is acceptable. > ... unless the sources are GPL'ed. Not shipping the original sources > would violate the GPL. Sounds like FUD. Could you elaborate a bit more? For me, this would clearly be a case of "work based on the program", which is something the GPL permits and even encourages (see section 2 of the license). Anyway, in this particular case, if the original program states it's GPL'ed when it in fact contains bits of incompatible-licensed code, it's quite a different situation :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.51 1.46 1.21 From tcallawa at redhat.com Mon Apr 25 15:47:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 25 Apr 2005 10:47:07 -0500 Subject: OT: GPL status of modified source (Was Re: Octave-forge and legal issues) In-Reply-To: <20050425173510.3f88164d@python2> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> <20050425173510.3f88164d@python2> Message-ID: <1114444027.3778.65.camel@localhost.localdomain> On Mon, 2005-04-25 at 17:35 +0200, Matthias Saou wrote: > Ralf Corsepius wrote : > > > On Mon, 2005-04-25 at 16:56 +0200, Matthias Saou wrote: > > > Quentin Spencer wrote : > > > > > > > 2. Create a modified source tarball with the offending code removed. > > > > This would be easy, but the source wouldn't match the upstream source. > > > > > > This has already been done for some packages (e.g. xmms, gstreamer- > > > plugins), and AFAIK is acceptable. > > ... unless the sources are GPL'ed. Not shipping the original sources > > would violate the GPL. > > Sounds like FUD. Could you elaborate a bit more? For me, this would > clearly be a case of "work based on the program", which is something the > GPL permits and even encourages (see section 2 of the license). Yeah, I'm pretty sure that its not a violation. (IANAL) It counts as a "modified" version of GPL code. Doesn't stop it from being GPL. ~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 mattdm at mattdm.org Mon Apr 25 15:46:24 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 11:46:24 -0400 Subject: Octave-forge and legal issues In-Reply-To: <1114442589.7227.121.camel@mccallum.corsepiu.local> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> Message-ID: <20050425154623.GA12112@jadzia.bu.edu> On Mon, Apr 25, 2005 at 05:23:09PM +0200, Ralf Corsepius wrote: > > > 2. Create a modified source tarball with the offending code removed. > > > This would be easy, but the source wouldn't match the upstream source. > > This has already been done for some packages (e.g. xmms, gstreamer- > > plugins), and AFAIK is acceptable. > ... unless the sources are GPL'ed. Not shipping the original sources > would violate the GPL. Um, if they're not commercially-distributable, they're not GPL'd. I don't see anything in the GPL that says you must distribute the sources in the exact same tarball as comes from upstream -- in fact, part of the point of the GPL is that you *don't* have to do that. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 72 degrees Fahrenheit. From tmraz at redhat.com Mon Apr 25 15:48:43 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 25 Apr 2005 17:48:43 +0200 Subject: Octave-forge and legal issues In-Reply-To: <1114442589.7227.121.camel@mccallum.corsepiu.local> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> Message-ID: <1114444123.5876.10.camel@perun.redhat.usu> On Mon, 2005-04-25 at 17:23 +0200, Ralf Corsepius wrote: > On Mon, 2005-04-25 at 16:56 +0200, Matthias Saou wrote: > > Quentin Spencer wrote : > > > > > 2. Create a modified source tarball with the offending code removed. > > > This would be easy, but the source wouldn't match the upstream source. > > > > This has already been done for some packages (e.g. xmms, gstreamer- > > plugins), and AFAIK is acceptable. > ... unless the sources are GPL'ed. Not shipping the original sources > would violate the GPL. This is a nonsense. You don't have to ship original sources to comply with GPL. You only have to ship the sources from which the binaries are built otherwise you couldn't fork a GPLed project. -- Tomas Mraz From qspencer at ieee.org Mon Apr 25 15:51:10 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 10:51:10 -0500 Subject: Octave-forge and legal issues In-Reply-To: <20050425154623.GA12112@jadzia.bu.edu> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> <20050425154623.GA12112@jadzia.bu.edu> Message-ID: <426D11EE.2030903@ieee.org> Matthew Miller wrote: >On Mon, Apr 25, 2005 at 05:23:09PM +0200, Ralf Corsepius wrote: > > >>>>2. Create a modified source tarball with the offending code removed. >>>>This would be easy, but the source wouldn't match the upstream source. >>>> >>>> >>>This has already been done for some packages (e.g. xmms, gstreamer- >>>plugins), and AFAIK is acceptable. >>> >>> >>... unless the sources are GPL'ed. Not shipping the original sources >>would violate the GPL. >> >> > >Um, if they're not commercially-distributable, they're not GPL'd. I don't >see anything in the GPL that says you must distribute the sources in the >exact same tarball as comes from upstream -- in fact, part of the point of >the GPL is that you *don't* have to do that. > > This is all true... I hope all of you are discussing this hypothetically at this point and not in regards to octave-forge. This is a dead issue with regard to octave-forge because the original GPL label in the spec file was based on an erroneous assumption by the packager who is very embarrased by his mistake and has corrected it :) (See my previous post on this). From bugs.michael at gmx.net Mon Apr 25 16:07:09 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 25 Apr 2005 18:07:09 +0200 Subject: more games (plus crack-attack) In-Reply-To: References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> Message-ID: <20050425180709.73854068.bugs.michael@gmx.net> On Mon, 25 Apr 2005 11:28:08 -0400 (EDT), fedora-lists at rewster.org wrote: > Also, I have a spec file just about finished for crack-attack > (which looks like it's been forked from the old version at > aluminumangel, http://savannah.nongnu.org/projects/crack-attack) > > I'll post my specfile (for c-a) later this evening after doing a few last > embarassment checks. crack-attack can't be included as long as it is copies the trademarked Tetris. From gdk at redhat.com Mon Apr 25 16:19:22 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 25 Apr 2005 12:19:22 -0400 (EDT) Subject: Octave-forge and legal issues In-Reply-To: <426D03B2.4030400@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> Message-ID: I can guarantee you that the answer to 1. is very likely to be "no", fwiw. --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ On Mon, 25 Apr 2005, Quentin Spencer wrote: > I have resolved most of the problems with octave-forge this package > except one, and I don't know how best to proceed. Someone discovered > something in the source tree that I had forgotten about: there is a > nonfree source tree containing a few functions whose license prohibit > commercial redistribution. The nonfree tree is not built into the > resulting RPM, but the source would remain in the source tarball. I see > the following options: > > 1. Ask the legal department if this is allowed and can stay as it is. > 2. Create a modified source tarball with the offending code removed. > This would be easy, but the source wouldn't match the upstream source. > 3. Get the upstream maintainer to remove the offending source code (this > has been discussed and he has expressed a willingness to do that, but I > don't know how soon the next release will be, the current one is 6 > months old). > > Right now, I'd like to go with option 2 because it's something I can do > without waiting for anyone else. My question is, does this break any > established rules or preferred ways of doing things? > > regards, > Quentin > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From rc040203 at freenet.de Mon Apr 25 16:43:46 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 25 Apr 2005 18:43:46 +0200 Subject: OT: GPL status of modified source (Was Re: Octave-forge and legal issues) In-Reply-To: <1114444027.3778.65.camel@localhost.localdomain> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <1114442589.7227.121.camel@mccallum.corsepiu.local> <20050425173510.3f88164d@python2> <1114444027.3778.65.camel@localhost.localdomain> Message-ID: <1114447426.7227.160.camel@mccallum.corsepiu.local> On Mon, 2005-04-25 at 10:47 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-04-25 at 17:35 +0200, Matthias Saou wrote: > > Ralf Corsepius wrote : > > > > > On Mon, 2005-04-25 at 16:56 +0200, Matthias Saou wrote: > > > > Quentin Spencer wrote : > > > > > > > > > 2. Create a modified source tarball with the offending code removed. > > > > > This would be easy, but the source wouldn't match the upstream source. > > > > > > > > This has already been done for some packages (e.g. xmms, gstreamer- > > > > plugins), and AFAIK is acceptable. > > > ... unless the sources are GPL'ed. Not shipping the original sources > > > would violate the GPL. > > > > Sounds like FUD. Could you elaborate a bit more? For me, this would > > clearly be a case of "work based on the program", which is something the > > GPL permits and even encourages (see section 2 of the license). > > Yeah, I'm pretty sure that its not a violation. (IANAL) OK, I stand corrected. Ralf From fedora-lists at rewster.org Mon Apr 25 17:00:38 2005 From: fedora-lists at rewster.org (JP LaFleur) Date: Mon, 25 Apr 2005 13:00:38 -0400 (EDT) Subject: more games (plus crack-attack) In-Reply-To: <20050425180709.73854068.bugs.michael@gmx.net> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> Message-ID: On Mon, 25 Apr 2005, Michael Schwendt wrote: > On Mon, 25 Apr 2005 11:28:08 -0400 (EDT), fedora-lists at rewster.org wrote: > >> Also, I have a spec file just about finished for crack-attack >> (which looks like it's been forked from the old version at >> aluminumangel, http://savannah.nongnu.org/projects/crack-attack) >> >> I'll post my specfile (for c-a) later this evening after doing a few last >> embarassment checks. > > crack-attack can't be included as long as it is copies the trademarked > Tetris. FWIW, it's not a clone of Tetris, it's like Tetris-Attack. Guess you could argue the two are somewhat similar, but it's not the "handle a stream of falling blocks to make horizontal rows" play mechanic. Or is it a matter of the game using the name "Tetris Attack" in the description or documentation? -- JP LaFleur fedora-lists at rewster.org From adrian at lisas.de Mon Apr 25 17:12:12 2005 From: adrian at lisas.de (Adrian Reber) Date: Mon, 25 Apr 2005 19:12:12 +0200 Subject: sponsor and review request: rzip In-Reply-To: <20050424150322.GG11570@stingr.stingr.net> References: <20050424100720.GE11570@stingr.stingr.net> <20050424103448.GA25200@lisas.de> <20050424150322.GG11570@stingr.stingr.net> Message-ID: <20050425171212.GA552@lisas.de> On Sun, Apr 24, 2005 at 07:03:22PM +0400, Paul P Komkoff Jr wrote: > Replying to Adrian Reber: > > You shouldn't specify $RPM_BUILD_ROOT during %build. Although the path > > doesn't seem to be anywhere in the built package following patch > > should be applied: > > Done. Updated SRPM at the same location > http://gw6.sgu.ru/st/SRPMS/rzip-2.0-1.src.rpm Looks good: def565356064834503d603ba1cf61d5e rzip-2.0-1.src.rpm Sources match upstream: 8a88b445afba919b122a3899d6d26b2a rzip-2.0.tar.gz Spec looks good. Rebuilds cleanly in mach. Adrian -- Adrian Reber http://lisas.de/~adrian/ non-redundant fan failure -------------- 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 Mon Apr 25 17:32:47 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 25 Apr 2005 19:32:47 +0200 Subject: more games (plus crack-attack) In-Reply-To: References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> Message-ID: <20050425193247.6aebb38a.bugs.michael@gmx.net> On Mon, 25 Apr 2005 13:00:38 -0400 (EDT), JP LaFleur wrote: > On Mon, 25 Apr 2005, Michael Schwendt wrote: > > > On Mon, 25 Apr 2005 11:28:08 -0400 (EDT), fedora-lists at rewster.org wrote: > > > >> Also, I have a spec file just about finished for crack-attack > >> (which looks like it's been forked from the old version at > >> aluminumangel, http://savannah.nongnu.org/projects/crack-attack) > >> > >> I'll post my specfile (for c-a) later this evening after doing a few last > >> embarassment checks. > > > > crack-attack can't be included as long as it is copies the trademarked > > Tetris. > > FWIW, it's not a clone of Tetris, it's like Tetris-Attack. Guess you > could argue the two are somewhat similar, but it's not the "handle a > stream of falling blocks to make horizontal rows" play mechanic. Or is it > a matter of the game using the name "Tetris Attack" in the description or > documentation? First of all, the name Tetris and related names are trademarked. So, using that name--or even a confusingly similar name--for comparing the games would be a legal problem. With regard to the game concept, I don't think the original Tetris game is patented--one reason why so many clones exist. And I don't know about Tetris Attack, the game concept itself is probably not protected either. Btw, crack-attack is included at rpm.livna.org From fedora-lists at rewster.org Mon Apr 25 17:58:59 2005 From: fedora-lists at rewster.org (JP LaFleur) Date: Mon, 25 Apr 2005 13:58:59 -0400 (EDT) Subject: more games (plus crack-attack) In-Reply-To: <20050425193247.6aebb38a.bugs.michael@gmx.net> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> Message-ID: On Mon, 25 Apr 2005, Michael Schwendt wrote: > On Mon, 25 Apr 2005 13:00:38 -0400 (EDT), JP LaFleur wrote: > >> On Mon, 25 Apr 2005, Michael Schwendt wrote: >> >>> On Mon, 25 Apr 2005 11:28:08 -0400 (EDT), fedora-lists at rewster.org wrote: >>> >>>> Also, I have a spec file just about finished for crack-attack >>>> (which looks like it's been forked from the old version at >>>> aluminumangel, http://savannah.nongnu.org/projects/crack-attack) >>>> >>>> I'll post my specfile (for c-a) later this evening after doing a few last >>>> embarassment checks. >>> >>> crack-attack can't be included as long as it is copies the trademarked >>> Tetris. >> >> FWIW, it's not a clone of Tetris, it's like Tetris-Attack. Guess you >> could argue the two are somewhat similar, but it's not the "handle a >> stream of falling blocks to make horizontal rows" play mechanic. Or is it >> a matter of the game using the name "Tetris Attack" in the description or >> documentation? > > First of all, the name Tetris and related names are trademarked. So, using > that name--or even a confusingly similar name--for comparing the games > would be a legal problem. Right, and grepping for "etris" in the source tree results in 5 hits, in autopackage descriptions, and I think two or three times in the game's documentation. Would removing these references be acceptable, or would searching for the name "Tetris Attack" in the specfile or a patch still make the package unimportable? Or would it be required to come from upstream that way? > With regard to the game concept, I don't think > the original Tetris game is patented--one reason why so many clones exist. > And I don't know about Tetris Attack, the game concept itself is probably > not protected either. > > Btw, crack-attack is included at rpm.livna.org I know, but that is version 1.10 (from AluminumAngel, the original author, which was before the nongnu version, which is currently up to 1.13). > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- JP LaFleur fedora-lists at rewster.org From bugs.michael at gmx.net Mon Apr 25 18:10:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 25 Apr 2005 20:10:59 +0200 Subject: more games (plus crack-attack) In-Reply-To: References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> Message-ID: <20050425201059.22c8c5d4.bugs.michael@gmx.net> On Mon, 25 Apr 2005 13:58:59 -0400 (EDT), JP LaFleur wrote: > > First of all, the name Tetris and related names are trademarked. So, using > > that name--or even a confusingly similar name--for comparing the games > > would be a legal problem. > > Right, and grepping for "etris" in the source tree results in 5 hits, in > autopackage descriptions, and I think two or three times in the game's > documentation. Would removing these references be acceptable, or would > searching for the name "Tetris Attack" in the specfile or a patch still > make the package unimportable? Or would it be required to come from > upstream that way? IANAL, but I would say: the latter. E.g. you could not include URLs which link upstream's home page where they continue to use the Tetris trademark. Lawyers (or authorities at Red Hat) would need to comment on "clones" and "remakes" of such games. From tcallawa at redhat.com Mon Apr 25 18:20:24 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 25 Apr 2005 13:20:24 -0500 Subject: more games (plus crack-attack) In-Reply-To: <20050425201059.22c8c5d4.bugs.michael@gmx.net> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> <20050425201059.22c8c5d4.bugs.michael@gmx.net> Message-ID: <1114453224.3778.94.camel@localhost.localdomain> On Mon, 2005-04-25 at 20:10 +0200, Michael Schwendt wrote: > Lawyers (or authorities at Red Hat) would need to comment on "clones" and > "remakes" of such games. This almost certainly needs to be a legal review item: "Are clones of existing trademarked games legally permissable for Fedora Extras?" It may almost be safer to just let those packages live in Livna. ~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 qspencer at ieee.org Mon Apr 25 18:19:10 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 13:19:10 -0500 Subject: Octave-forge and legal issues In-Reply-To: <20050425165610.3f8a12e0@python2> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> Message-ID: <426D349E.5070505@ieee.org> Matthias Saou wrote: >Quentin Spencer wrote : > > > >>2. Create a modified source tarball with the offending code removed. >>This would be easy, but the source wouldn't match the upstream source. >> >> > >This has already been done for some packages (e.g. xmms, gstreamer- >plugins), and AFAIK is acceptable. Ideally, include as one of the >"SourceX:" lines a quick little script that can reproduce the modified >tarball from the original one (uncompress the original tarball, remove >this and that, recompress with the new tarball name). > >Matthias > > OK, what about this: Source0: ftp://download.sourceforge.net/pub/sourceforge/o/oc/octave/%{name}-%{version}.tar.gz Source1: %{name}-%{version}.patched.tar.gz Source2: %{name}-mktarball.sh NoSource: 0 .... %prep %setup -q -T -b 1 The octave-forge-mktarball.sh does basically what you described. I'm not familiar with the use of NoSource--I figured this out just now from Maximum RPM. Is this the right approach? I haven't built the whole package, but this seems do to what I want. -Quentin From gdk at redhat.com Mon Apr 25 18:26:37 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 25 Apr 2005 14:26:37 -0400 (EDT) Subject: Legal questions about games In-Reply-To: <1114453224.3778.94.camel@localhost.localdomain> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> <20050425201059.22c8c5d4.bugs.michael@gmx.net> <1114453224.3778.94.camel@localhost.localdomain> Message-ID: So let me have something better defined to take to legal. It seems to me that we've got three different categories: 1. Straight rip-offs of copyrighted games that we know are being defended. Tetris falls into this category. The answer is clearly no. 2. Straight rip-offs of copyrighted games for which no known policy by the copyright holder is clear. If someone comes up with "PyStratego" using the PyGames libs, is it acceptable or not? My guess is "probably no." 3. Games that mimic other licensed games, but use different names. Lots of precedent here for safety. We shipped freeciv in RHL forever; similarly, Reversi is a well-known workaround for the copyright of Othello. My guess is that we've got more room here. If I ask counsel about these three game categories, will that likely be sufficient? And I'd much rather not shunt these games out to Livna unless *absolutely* necessary. I think that being able to install cool games for Fedora straight out of box is a big win for us. --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ On Mon, 25 Apr 2005, Tom 'spot' Callaway wrote: > On Mon, 2005-04-25 at 20:10 +0200, Michael Schwendt wrote: > > > Lawyers (or authorities at Red Hat) would need to comment on "clones" and > > "remakes" of such games. > > This almost certainly needs to be a legal review item: > > "Are clones of existing trademarked games legally permissable for Fedora > Extras?" > > It may almost be safer to just let those packages live in Livna. > > ~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! > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From fedora at camperquake.de Mon Apr 25 18:30:57 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 25 Apr 2005 20:30:57 +0200 Subject: Octave-forge and legal issues In-Reply-To: <426D349E.5070505@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <426D349E.5070505@ieee.org> Message-ID: <20050425203057.6dfc078e@nausicaa.camperquake.de> Hi. Quentin Spencer wrote: > The octave-forge-mktarball.sh does basically what you described. I'm > not familiar with the use of NoSource--I figured this out just now from > Maximum RPM. Is this the right approach? I haven't built the whole > package, but this seems do to what I want. Why don't you just build from a tarball with the offending source removed? I do the same for the mp3 decoder in bmp. -- I was just reading a book about chaos. In it, it mentions a mathematician who did ground breaking work in Chaos theory using his computer which did a blazing six floating point operations per second. My computer does 120 million. I haven't discovered shit. -- Amit Raam From qspencer at ieee.org Mon Apr 25 18:34:40 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 13:34:40 -0500 Subject: Octave-forge and legal issues In-Reply-To: <20050425203057.6dfc078e@nausicaa.camperquake.de> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <426D349E.5070505@ieee.org> <20050425203057.6dfc078e@nausicaa.camperquake.de> Message-ID: <426D3840.1020305@ieee.org> Ralf Ertzinger wrote: >Quentin Spencer wrote: > > > >>The octave-forge-mktarball.sh does basically what you described. I'm >>not familiar with the use of NoSource--I figured this out just now from >>Maximum RPM. Is this the right approach? I haven't built the whole >>package, but this seems do to what I want. >> >> > >Why don't you just build from a tarball with the offending source removed? >I do the same for the mp3 decoder in bmp. > > That's my plan. I was just following Matthias's suggestion that I include a script that I used to build the tarball, and I was wondering if it made any sense to include the original source but omit it using NoSource, so that it is well documented how I arrived at the tarball that is actually being used. From tcallawa at redhat.com Mon Apr 25 18:39:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 25 Apr 2005 13:39:50 -0500 Subject: Octave-forge and legal issues In-Reply-To: <426D3840.1020305@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <426D349E.5070505@ieee.org> <20050425203057.6dfc078e@nausicaa.camperquake.de> <426D3840.1020305@ieee.org> Message-ID: <1114454391.3778.97.camel@localhost.localdomain> On Mon, 2005-04-25 at 13:34 -0500, Quentin Spencer wrote: > That's my plan. I was just following Matthias's suggestion that I > include a script that I used to build the tarball, and I was wondering > if it made any sense to include the original source but omit it using > NoSource, so that it is well documented how I arrived at the tarball > that is actually being used. Don't NoSource it. Just edit the source to remove the questionable bits, and document what you did, without including the source that you removed (aka, don't provide a diff). Also, rename the tarball, so that it is obvious. ~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 mattdm at mattdm.org Mon Apr 25 18:46:22 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 14:46:22 -0400 Subject: more games (plus crack-attack) In-Reply-To: <20050425193247.6aebb38a.bugs.michael@gmx.net> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> Message-ID: <20050425184622.GA17687@jadzia.bu.edu> On Mon, Apr 25, 2005 at 07:32:47PM +0200, Michael Schwendt wrote: > First of all, the name Tetris and related names are trademarked. So, using > that name--or even a confusingly similar name--for comparing the games > would be a legal problem. With regard to the game concept, I don't think A pretty tenuous problem. Using names descriptively is fair use. (Even if you're advertising something, you don't have to say "that long race they had last week in that big New England city" -- you can say "Boston Marathon", *even though* Boston Marathon is a trademark.) The people who own Tetris, however, claim that they have a "look and feel" copyright on the game that covers anything remotely similar. This is probably ridiculous too, but they've apparently got the money to threaten people about it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 75 degrees Fahrenheit. From paul at all-the-johnsons.co.uk Mon Apr 25 19:09:32 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 25 Apr 2005 20:09:32 +0100 Subject: Request package sponsorship Message-ID: <1114456172.15474.1.camel@localhost> Hi, Could someone please sponsor mysqlcc? From what I can see, other than a small issue with Qt, this package should just fit in with the other SQL software bundled with extras. TTFN Paul -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 qspencer at ieee.org Mon Apr 25 20:21:20 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Mon, 25 Apr 2005 15:21:20 -0500 Subject: Review Request: octave-forge In-Reply-To: <426D01D5.6080605@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D01D5.6080605@ieee.org> Message-ID: <426D5140.6010408@ieee.org> I think I have now resolved all problems with octave-forge, and have checked the changes into CVS. I'm now requesting a new review. thanks, Quentin From kaboom at oobleck.net Mon Apr 25 20:21:50 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 25 Apr 2005 16:21:50 -0400 (EDT) Subject: packages for review: openbox and friends In-Reply-To: <20050423155830.GB9919@lisas.de> References: <20050420052915.GA11961@lisas.de> <20050423155830.GB9919@lisas.de> Message-ID: On Sat, 23 Apr 2005, Adrian Reber wrote: > You need to add glib2-devel, libxml2-devel and > startup-notification-devel as BuildRequires and can then remove the > XFree86-devel BR because that will be pulled in by > startup-notification-devel. The same is true for fontconfig-devel as it > is pulled in by xorg-x11-devel: > > BuildRequires: bison libxml2-devel > BuildRequires: startup-notification-devel glib2-devel Thanks, fixed > %post and %postun could be %post(un) -p /sbin/ldconfig and you can then > remove Requires(post(un)): /sbin/ldconfig I changed this as well and removed the forced Requires Just so I'm clear: I can remove the Requires(post*) because the automatic dependency generation stuff is smart enough to add it automatically for the one-liner version (%post -p /sbin/ldconfig) but not smart enough for the shell out (%post \r /sbin/ldconfig)? > I have seen in other reviews that install should use the -p flag to > preserve timestamps. And maybe you could use either cp or install and > not mix it. But that is up to you. changed install to cp -p Thanks! later, chris From bugs.michael at gmx.net Mon Apr 25 20:35:20 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 25 Apr 2005 22:35:20 +0200 Subject: more games (plus crack-attack) In-Reply-To: <20050425184622.GA17687@jadzia.bu.edu> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> <20050425184622.GA17687@jadzia.bu.edu> Message-ID: <20050425223520.049bb717.bugs.michael@gmx.net> On Mon, 25 Apr 2005 14:46:22 -0400, Matthew Miller wrote: > On Mon, Apr 25, 2005 at 07:32:47PM +0200, Michael Schwendt wrote: > > First of all, the name Tetris and related names are trademarked. So, using > > that name--or even a confusingly similar name--for comparing the games > > would be a legal problem. With regard to the game concept, I don't think > > A pretty tenuous problem. Using names descriptively is fair use. (Even if > you're advertising something, you don't have to say "that long race they had > last week in that big New England city" -- you can say "Boston Marathon", > *even though* Boston Marathon is a trademark.) "Fair use" of trademarks in conjunction with advertising is not that simple. The question is where to draw the line? You could run into problems advertising your video gaming console with something like "includes the 200 most popular game titles, such as Break-It, a Tetris style game, and...", even if the Tetris game concept is not protected. Concerning Boston Marathon, the example you give doesn't advertise anything. Try advertising your own marathon (or half-marathon even) with a reference, something like "The 5th Somerville Individuals Marathon 2005, with almost 3000 registered runners in last year the smaller edition of Boston Marathon...". > The people who own Tetris, however, claim that they have a "look and feel" > copyright on the game that covers anything remotely similar. This is > probably ridiculous too, but they've apparently got the money to threaten > people about it. And therefore it would be an even higher risk to create a specific connection between a protected game design and something which started as a "remake". From kaboom at oobleck.net Mon Apr 25 20:40:06 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Mon, 25 Apr 2005 16:40:06 -0400 (EDT) Subject: request for review: tre In-Reply-To: <1114291593.30784.22.camel@rydia.hardsun.net> References: <1114291593.30784.22.camel@rydia.hardsun.net> Message-ID: On Sat, 23 Apr 2005, Aaron Kurtz wrote: > On Sat, 2005-04-23 at 07:21 -0400, Chris Ricker wrote: > > > > > > tre is primarily a POSIX-compliant regexp library, but with support for > > arbitrarily approximate matching. The package also includes agrep, a fuzzy > > grep built using this library. > > > > Anyone care to review / sponsor? > > rpmlint says > W: tre summary-not-capitalized lightweight POSIX-compliant regexp > library > Is this an important style point here? I've always ignored that particular rpmlint error, but it's not like I care. What's the general consensus? Existing packages don't seem to pay a lot of attention to that one or to the no-trailing-periods one.... > E: tre non-versioned-file-in-library-package /usr/share/man > > various complaints about this for various files, which will make it > impossible to have multiple versions installed at once, but this doesn't > seem to truly matter. I thought these were generally harmless? > E: tre standard-dir-owned-by-package /usr/share/man > E: tre standard-dir-owned-by-package /usr/share/man/man1 > > This on the other hand should be fixed. %{_datadir}/* is causing it, and > you don't want to do this. For one thing, both tre and tre-agrep > own /usr/share/man/man1/agrep.1.gz thanks, fixed. The real problem, I think, was that I'd done %{_datadir} instead of just doing locale stuff > W: tre one-line-command-in-%post /sbin/ldconfig > W: tre one-line-command-in-%postun /sbin/ldconfig > > http://fedoraproject.org/wiki/ScriptletSnippets suggests but doesn't > require doing this as %post -p /sbin/ldconfig and so. Changed Thanks! later, chris From bugs.michael at gmx.net Mon Apr 25 20:45:02 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 25 Apr 2005 22:45:02 +0200 Subject: Octave-forge and legal issues In-Reply-To: <426D349E.5070505@ieee.org> References: <1114370506.7060.2.camel@localhost.localdomain> <0ML29c-1DPnTK24fe-0004OH@mrelayeu.kundenserver.de> <20050424224305.459ef0b5.bugs.michael@gmx.net> <426D03B2.4030400@ieee.org> <20050425165610.3f8a12e0@python2> <426D349E.5070505@ieee.org> Message-ID: <20050425224502.0eb04b66.bugs.michael@gmx.net> On Mon, 25 Apr 2005 13:19:10 -0500, Quentin Spencer wrote: > OK, what about this: > > Source0: > ftp://download.sourceforge.net/pub/sourceforge/o/oc/octave/%{name}-%{version}.tar.gz > Source1: %{name}-%{version}.patched.tar.gz > Source2: %{name}-mktarball.sh > NoSource: 0 > > .... > > %prep > %setup -q -T -b 1 > > > The octave-forge-mktarball.sh does basically what you described. I'm not > familiar with the use of NoSource--I figured this out just now from > Maximum RPM. Is this the right approach? I haven't built the whole > package, but this seems do to what I want. The tarball specified as Source0 would be extracted and used for the build, if available and if you didn't make %setup extract Source1 instead. NoSource just excludes SourceX files from the src.rpm, but uses them during rebuild, if available. The less complicated version would be this: # ftp://download.sourceforge.net/pub/sourceforge/o/oc/octave/%{name}-%{version}.tar.gz Source0: %{name}-%{version}.patched.tar.gz Source1: %{name}-mktarball.sh %prep %setup -q Btw, do the ftp:// SF.net locations still exist? From mattdm at mattdm.org Mon Apr 25 20:48:17 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 25 Apr 2005 16:48:17 -0400 Subject: more games (plus crack-attack) In-Reply-To: <20050425223520.049bb717.bugs.michael@gmx.net> References: <1114375078.5382.10.camel@marte.biciclete.ro> <20050424210625.GA12989@jadzia.bu.edu> <1114405625.2993.2.camel@marte.biciclete.ro> <20050425122226.GA2427@jadzia.bu.edu> <20050425180709.73854068.bugs.michael@gmx.net> <20050425193247.6aebb38a.bugs.michael@gmx.net> <20050425184622.GA17687@jadzia.bu.edu> <20050425223520.049bb717.bugs.michael@gmx.net> Message-ID: <20050425204816.GA22961@jadzia.bu.edu> On Mon, Apr 25, 2005 at 10:35:20PM +0200, Michael Schwendt wrote: > Concerning Boston Marathon, the example you give doesn't advertise > anything. Try advertising your own marathon (or half-marathon even) > with a reference, something like "The 5th Somerville Individuals > Marathon 2005, with almost 3000 registered runners in last year the > smaller edition of Boston Marathon...". Yep. It's important how you say what you say, and all that gray area is why we have lawyers. Oh what fun. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From ivazquez at ivazquez.net Mon Apr 25 21:26:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 25 Apr 2005 17:26:18 -0400 Subject: Review Request: inadyn In-Reply-To: References: Message-ID: <1114464378.7784.49.camel@ignacio.ignacio.lan> On Mon, 2005-04-25 at 15:46 +0200, Jochen Schmitt wrote: > Hello, > > it will be nice, if anyone can review the package inadyn-1.90, > which you may find at: > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm No, it's in CVS, so the copy in CVS needs to be reviewed. Anyways... + URL checks out + Source0 md5sum matches - Source0 isn't a complete URL * Might want to consider writing an initscript for 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 bugs.michael at gmx.net Tue Apr 26 08:18:29 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Apr 2005 10:18:29 +0200 Subject: Review Request: inadyn In-Reply-To: <1114464378.7784.49.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> Message-ID: <20050426101829.75c1ab59.bugs.michael@gmx.net> On Mon, 25 Apr 2005 17:26:18 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-04-25 at 15:46 +0200, Jochen Schmitt wrote: > > Hello, > > > > it will be nice, if anyone can review the package inadyn-1.90, > > which you may find at: > > > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm > > No, it's in CVS, so the copy in CVS needs to be reviewed. Anyways... > > + URL checks out > + Source0 md5sum matches > - Source0 isn't a complete URL > * Might want to consider writing an initscript for it Did you change your mind about the package? https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00288.html From ivazquez at ivazquez.net Tue Apr 26 08:28:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 26 Apr 2005 04:28:16 -0400 Subject: Review Request: inadyn In-Reply-To: <20050426101829.75c1ab59.bugs.michael@gmx.net> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> Message-ID: <1114504096.7784.57.camel@ignacio.ignacio.lan> On Tue, 2005-04-26 at 10:18 +0200, Michael Schwendt wrote: > On Mon, 25 Apr 2005 17:26:18 -0400, Ignacio Vazquez-Abrams wrote: > > > On Mon, 2005-04-25 at 15:46 +0200, Jochen Schmitt wrote: > > > Hello, > > > > > > it will be nice, if anyone can review the package inadyn-1.90, > > > which you may find at: > > > > > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm > > > > No, it's in CVS, so the copy in CVS needs to be reviewed. Anyways... > > > > + URL checks out > > + Source0 md5sum matches > > - Source0 isn't a complete URL > > * Might want to consider writing an initscript for it > > Did you change your mind about the package? > https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00288.html Sponsoring and Package Review are two separate processes, at least according to the New Package Process in the wiki. Sponsoring is covered under Section I, Package Review under Section III. In my mind, Sponsoring covers minor cleanups that should be done before a package can/should be done before bringing it into CVS, whereas Package Review is meant to tighten up the package for production use. -- 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 Apr 26 10:29:02 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Apr 2005 12:29:02 +0200 Subject: Review Request: inadyn In-Reply-To: <1114504096.7784.57.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> Message-ID: <20050426122902.22ebdbba.bugs.michael@gmx.net> On Tue, 26 Apr 2005 04:28:16 -0400, Ignacio Vazquez-Abrams wrote: > > > > http://www.herr-schmitt.de/pub/inadyn/inadyn-1.90-3.src.rpm > > > > > > No, it's in CVS, so the copy in CVS needs to be reviewed. Anyways... > > > > > > + URL checks out > > > + Source0 md5sum matches > > > - Source0 isn't a complete URL > > > * Might want to consider writing an initscript for it > > > > Did you change your mind about the package? > > https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00288.html > > Sponsoring and Package Review are two separate processes, at least > according to the New Package Process in the wiki. Sponsoring is covered > under Section I, Package Review under Section III. > > In my mind, Sponsoring covers minor cleanups that should be done before > a package can/should be done before bringing it into CVS, whereas > Package Review is meant to tighten up the package for production use. You misunderstood my comment. Earlier on fedora-commits-list, you wrote: > You never requested a review, so how can this possibly be approved? Above link into the archives points to a message, where you replied to Jochen's request for review and even imported his src.rpm later. What surprised me is that it doesn't become clear when or whether you would approve the package and what would be absolutely required before you [the sponsor] would approve it. With regard to what you wrote above about the Wiki: If that is what other contributors read into the NewPackageProcess Wiki page, too, we should change it and make it less ambiguous. More proof that the current process is ambiguous, apparently, can be found in fedora-extras-commits archives, where packages in CVS have no sponsor yet. Obviously, _prior_ to sponsoring a new package and prior to importing it into CVS, a new package must be reviewed painstakingly and any issues be discussed with the packager. The important and relevant reviewing happens prior to CVS import. That way, new packagers, who don't have CVS access yet, can get packages included, too. The sponsor, who takes over security relevant checks (e.g. verification of upstream locations, tarball origin, licencing), works with a packager on a first package version, so it can be imported into CVS, where more people see it and can comment on any oddities. Basically, that is the sponsor's approval already, but the actual APPROVED message is delayed, because after cvs import, other contributors might still have some to add or might even block a package. Post-commit reviews, in particular those which only comment on diffs posted to fedora-extras-commits list, are no substitute for real reviews done by somebody. For instance, who does test-builds, examines package contents, and gives binaries a try at run-time prior to approval? The sponsor? Or just the packager? An approval means what? -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1258_FC4 loadavg: 1.14 1.17 1.10 From gauret at free.fr Tue Apr 26 10:29:19 2005 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 26 Apr 2005 12:29:19 +0200 Subject: libvisual References: <1114433969.1438.8.camel@fc4t2.mpeters.local> Message-ID: Michael A. Peters wrote: > I see that libvisual is in Extras - but I don't see any > libvisual-plugins package. I packaged libvisual at first as an amaroK dependency. I intended to package libvisual-plugins at some point, but never found the time (and forgot about it...) Feel free to package it if you want. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr No, I coded it crappily on purpose, just so that I could say "There's plenty of room for optimization." From mpeters at mac.com Tue Apr 26 11:16:17 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 26 Apr 2005 04:16:17 -0700 Subject: libvisual In-Reply-To: References: <1114433969.1438.8.camel@fc4t2.mpeters.local> Message-ID: <1114514177.7831.8.camel@fc4t2.mpeters.local> On Tue, 2005-04-26 at 12:29 +0200, Aurelien Bompard wrote: > Michael A. Peters wrote: > > I see that libvisual is in Extras - but I don't see any > > libvisual-plugins package. > > I packaged libvisual at first as an amaroK dependency. I intended to package > libvisual-plugins at some point, but never found the time (and forgot about > it...) > Feel free to package it if you want. There is a hitch with it - it libvisual-plugins package does not compile with gcc4. So it would need to be patched to do so, I assume that packages should compile with the default compiler, and the fact that it doesn't means there is probably a problem with the code. That being said, when compiled with gcc32 they do work beautifully with the gstreamer libvisual plugin compiled against the libvisual package in rawhide (tested with totem). If I can get them to compile with gcc4 I will submit a package for review. It might be as simple as disabling one of the plugins until upstream fixes it (haven't looked at where it failed). From ivazquez at ivazquez.net Tue Apr 26 11:40:50 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 26 Apr 2005 07:40:50 -0400 Subject: New Package Process (was: Re: Review Request: inadyn) In-Reply-To: <20050426122902.22ebdbba.bugs.michael@gmx.net> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> Message-ID: <1114515650.7784.80.camel@ignacio.ignacio.lan> On Tue, 2005-04-26 at 12:29 +0200, Michael Schwendt wrote: > On Tue, 26 Apr 2005 04:28:16 -0400, Ignacio Vazquez-Abrams wrote: > > > > Did you change your mind about the package? > > > https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00288.html > > > > Sponsoring and Package Review are two separate processes, at least > > according to the New Package Process in the wiki. Sponsoring is covered > > under Section I, Package Review under Section III. > > > > In my mind, Sponsoring covers minor cleanups that should be done before > > a package can/should be done before bringing it into CVS, whereas > > Package Review is meant to tighten up the package for production use. > > You misunderstood my comment. Earlier on fedora-commits-list, you wrote: > > > You never requested a review, so how can this possibly be approved? > > Above link into the archives points to a message, where you replied > to Jochen's request for review and even imported his src.rpm later. Aha. I see lots of people asking for a "review" when they're looking for a package sponsor, so I figured that this would be the same thing. > What surprised me is that it doesn't become clear when or whether > you would approve the package and what would be absolutely required > before you [the sponsor] would approve it. It doesn't say in the wiki that the sponsor and the reviewer have to be the same person. If this should be so then it might be prudent to spell it out. > With regard to what you wrote above about the Wiki: > > If that is what other contributors read into the NewPackageProcess Wiki > page, too, we should change it and make it less ambiguous. > > More proof that the current process is ambiguous, apparently, can be found > in fedora-extras-commits archives, where packages in CVS have no sponsor > yet. Honestly, I have no clue how other contributors read it. Or even *if* they read it, for that matter. I only see 4 links to it, one off the main Extras page, one off the CVS FAQ page (which is blue-on-blue, btw), and 2 red herrings. I don't think enough emphasis is placed on that process, since as you mentioned some packages have slipped in regardless. > Obviously, _prior_ to sponsoring a new package and prior to importing it > into CVS, a new package must be reviewed painstakingly and any issues be > discussed with the packager. The important and relevant reviewing happens > prior to CVS import. That way, new packagers, who don't have CVS access > yet, can get packages included, too. > > The sponsor, who takes over security relevant checks (e.g. verification of > upstream locations, tarball origin, licencing), works with a packager on a > first package version, so it can be imported into CVS, where more people > see it and can comment on any oddities. Basically, that is the sponsor's > approval already, but the actual APPROVED message is delayed, because > after cvs import, other contributors might still have some to add or might > even block a package. Excellent. Very worth adding to the wiki, possibly as subsection Ia of the New Package Process. > Post-commit reviews, in particular those which only comment on diffs > posted to fedora-extras-commits list, are no substitute for real reviews > done by somebody. For instance, who does test-builds, examines package > contents, and gives binaries a try at run-time prior to approval? The > sponsor? Or just the packager? An approval means what? All very good points. When I sponsor a package I make sure it at least builds on i386 (because that's all I have atm) without barfing. The actual binary sometimes doesn't get tested until I review it (although if I like a package's idea I'll try it out early). -- 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 Apr 26 11:53:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Apr 2005 13:53:22 +0200 Subject: New Package Process (was: Re: Review Request: inadyn) In-Reply-To: <1114515650.7784.80.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> Message-ID: <20050426135322.754a1d2d.bugs.michael@gmx.net> On Tue, 26 Apr 2005 07:40:50 -0400, Ignacio Vazquez-Abrams wrote: > It doesn't say in the wiki that the sponsor and the reviewer have to be > the same person. If this should be so then it might be prudent to spell > it out. What does it mean "to be a package sponsor"? What are a package sponsor's obligations? From i at stingr.net Tue Apr 26 12:51:17 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Tue, 26 Apr 2005 16:51:17 +0400 Subject: sponsor and review request: rzip In-Reply-To: <20050425171212.GA552@lisas.de> References: <20050424100720.GE11570@stingr.stingr.net> <20050424103448.GA25200@lisas.de> <20050424150322.GG11570@stingr.stingr.net> <20050425171212.GA552@lisas.de> Message-ID: <20050426125117.GH11570@stingr.stingr.net> Replying to Adrian Reber: > Looks good: > > def565356064834503d603ba1cf61d5e rzip-2.0-1.src.rpm > > Sources match upstream: > > 8a88b445afba919b122a3899d6d26b2a rzip-2.0.tar.gz > > Spec looks good. Rebuilds cleanly in mach. What's next? -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available URL: From bdpepple at ameritech.net Tue Apr 26 13:11:32 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Tue, 26 Apr 2005 09:11:32 -0400 Subject: Review Request: inadyn In-Reply-To: <20050426122902.22ebdbba.bugs.michael@gmx.net> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> Message-ID: <1114521092.7166.26.camel@localhost.localdomain> On Tue, 2005-04-26 at 12:29 +0200, Michael Schwendt wrote: > Obviously, _prior_ to sponsoring a new package and prior to importing it > into CVS, a new package must be reviewed painstakingly and any issues be > discussed with the packager. The important and relevant reviewing happens > prior to CVS import. That way, new packagers, who don't have CVS access > yet, can get packages included, too. > > The sponsor, who takes over security relevant checks (e.g. verification of > upstream locations, tarball origin, licencing), works with a packager on a > first package version, so it can be imported into CVS, where more people > see it and can comment on any oddities. Basically, that is the sponsor's > approval already, but the actual APPROVED message is delayed, because > after cvs import, other contributors might still have some to add or might > even block a package. On the wiki's first step, it only mentions verifying any legal issues, and having a Extras Contributor sponsor it. I believe we should also mention verifying the upstream source location and source integrity. Also, I think a more thorough check of the spec could be handled after the CVS import (as it currently states on the wiki), so more people could see it. Hopefully, this would make it less of a burden for the sponsor, since more people would be involved in ironing out issues with the spec. /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 Jochen at herr-schmitt.de Tue Apr 26 14:59:45 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 26 Apr 2005 16:59:45 +0200 Subject: Review Request: inadyn In-Reply-To: <1114464378.7784.49.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> Message-ID: <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> On Mon, 25 Apr 2005 17:26:18 -0400, you wrote: >* Might want to consider writing an initscript for it The upstream mainainer has wrote, that he wants to include a pid handle option in the next version of inadyn. That was the reason, why I have diced to defer a implementation of a init script after the release of the next version. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Tue Apr 26 16:49:19 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 26 Apr 2005 18:49:19 +0200 Subject: Review Request: inadyn In-Reply-To: <1114464378.7784.49.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> Message-ID: <0MKwpI-1DQTFO3w46-0002Cq@mrelayeu.kundenserver.de> On Mon, 25 Apr 2005 17:26:18 -0400, you wrote: >- Source0 isn't a complete URL Fixed and checked in. Best Regards: Jochen Schmitt From hula-kevin at iprone.com Tue Apr 26 18:24:30 2005 From: hula-kevin at iprone.com (Kevin Gray) Date: Tue, 26 Apr 2005 14:24:30 -0400 Subject: Request for Review: hula In-Reply-To: <20050416113846.4c8d83cd.bugs.michael@gmx.net> References: <200504152033.23317.hula-kevin@iprone.com> <20050416113846.4c8d83cd.bugs.michael@gmx.net> Message-ID: <426E875E.8060908@iprone.com> Michael, Sorry for the delay in responding to your suggestions, I had an issue uploading my package which has now been resolved. I believe the only thing I havent answered is the tarball issue, where you mentioned getting one that doesnt require running the autogen.sh. I do have a question about that if you dont mind. Im just curious to know what the advantage is to doing this. Also, I removed the irrelevant and empty docs from the package. A new version has been uploaded for anyone to review. K From j.w.r.degoede at hhs.nl Tue Apr 26 18:29:56 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 26 Apr 2005 20:29:56 +0200 Subject: Glide3 inclusion? (in progress) In-Reply-To: <20050418011621.37c327b7@python2> References: <20050418011621.37c327b7@python2> Message-ID: <426E88A4.8000803@hhs.nl> Just for those interested, I'm working on this but gcc4 hates the Glide3 code, so far all fixable but taking more time then I thought it would. Regards, Hans From bugs.michael at gmx.net Tue Apr 26 18:38:23 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Apr 2005 20:38:23 +0200 Subject: Request for Review: hula In-Reply-To: <426E875E.8060908@iprone.com> References: <200504152033.23317.hula-kevin@iprone.com> <20050416113846.4c8d83cd.bugs.michael@gmx.net> <426E875E.8060908@iprone.com> Message-ID: <20050426203823.23ad12cd.bugs.michael@gmx.net> On Tue, 26 Apr 2005 14:24:30 -0400, Kevin Gray wrote: > Michael, > > Sorry for the delay in responding to your suggestions, I had an issue > uploading my package which has now been resolved. I believe the only > thing I havent answered is the tarball issue, where you mentioned > getting one that doesnt require running the autogen.sh. I do have a > question about that if you dont mind. Im just curious to know what the > advantage is to doing this. It is a bug if you must have the tools required by autogen.sh and possibly specific versions of those tools. The source code archive should be ready to use as soon as it is extracted, so you could call "configure" without the need to create the file yourself [by running autogen.sh] beforehand. The source code maintainers ought to run autogen.sh prior to creating the tarball and publishing it. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.14_FC3 loadavg: 1.13 1.13 1.02 From ed at eh3.com Tue Apr 26 18:46:52 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 26 Apr 2005 14:46:52 -0400 Subject: Request for Review: hula In-Reply-To: <20050426203823.23ad12cd.bugs.michael@gmx.net> References: <200504152033.23317.hula-kevin@iprone.com> <20050416113846.4c8d83cd.bugs.michael@gmx.net> <426E875E.8060908@iprone.com> <20050426203823.23ad12cd.bugs.michael@gmx.net> Message-ID: <1114541212.30547.10.camel@ernie> On Tue, 2005-04-26 at 20:38 +0200, Michael Schwendt wrote: > On Tue, 26 Apr 2005 14:24:30 -0400, Kevin Gray wrote: > > > Michael, > > > > Sorry for the delay in responding to your suggestions, I had an issue > > uploading my package which has now been resolved. I believe the only > > thing I havent answered is the tarball issue, where you mentioned > > getting one that doesnt require running the autogen.sh. I do have a > > question about that if you dont mind. Im just curious to know what the > > advantage is to doing this. > > It is a bug if you must have the tools required by autogen.sh and possibly > specific versions of those tools. The source code archive should be ready > to use as soon as it is extracted, so you could call "configure" without > the need to create the file yourself [by running autogen.sh] beforehand. > The source code maintainers ought to run autogen.sh prior to creating the > tarball and publishing it. Hi Michael, Just out of curiosity, is there a policy in place for instances where you'd like to change the way that, say, something is handled in a Makefile.am (that is, change wrt the upstream)? What I'm trying to get at is this: does Fedora Extras have a policy that specifically forbids the use of the auto-tools within spec files? And if so, does it mean that one should instead supply a new "configure" script as a patch? 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 mricon at gmail.com Tue Apr 26 19:22:06 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 26 Apr 2005 15:22:06 -0400 Subject: Suggestion: pylint In-Reply-To: <1114230554l.2872l.0l@devel.mpeters.local> References: <1114230554l.2872l.0l@devel.mpeters.local> Message-ID: On 4/23/05, Michael A. Peters wrote: > > Pylint is a useful tool for extra-anal Python code analysis for > > errors > > and poor habits. It is used by PyDev in Eclipse if available (PyDev > > is > > part of FC4), so I think it's good if Pylint is added to Extras. > > > > I have created the RPMs for the first looking-over. See: > > http://phy.duke.edu/~icon/misc/fedora-extras/ > > I believe extras wants you to %ghost the *.pyo files in site-packages I wanted to do that, but it would appear that both pylint and python-logilab-common build .pyo versions by default, so they should be owned without having to specify %ghost. Regards, -- Konstantin Ryabitsev Zlotniks, INC From mricon at gmail.com Tue Apr 26 19:33:28 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 26 Apr 2005 15:33:28 -0400 Subject: Suggestion: pylint In-Reply-To: References: <1114230554l.2872l.0l@devel.mpeters.local> Message-ID: On 4/26/05, Konstantin Ryabitsev wrote: > > I believe extras wants you to %ghost the *.pyo files in site-packages > > I wanted to do that, but it would appear that both pylint and > python-logilab-common build .pyo versions by default, so they should > be owned without having to specify %ghost. Never mind me, I'm slow. :) Is there any concensus on .pyo files? Do we want to %ghost them, pre-build them, or not worry about them at all? -- Konstantin Ryabitsev Zlotniks, INC From bugs.michael at gmx.net Tue Apr 26 19:45:41 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 26 Apr 2005 21:45:41 +0200 Subject: Request for Review: hula In-Reply-To: <1114541212.30547.10.camel@ernie> References: <200504152033.23317.hula-kevin@iprone.com> <20050416113846.4c8d83cd.bugs.michael@gmx.net> <426E875E.8060908@iprone.com> <20050426203823.23ad12cd.bugs.michael@gmx.net> <1114541212.30547.10.camel@ernie> Message-ID: <20050426214541.2ef0f6a2.bugs.michael@gmx.net> On Tue, 26 Apr 2005 14:46:52 -0400, Ed Hill wrote: > Hi Michael, > > Just out of curiosity, is there a policy in place for instances where > you'd like to change the way that, say, something is handled in a > Makefile.am (that is, change wrt the upstream)? No policy. Though, as with most patches, you should try to get them applied upstream. ;) > What I'm trying to get at is this: does Fedora Extras have a policy that > specifically forbids the use of the auto-tools within spec files? No. > And if so, does it mean that one should instead supply a new "configure" > script as a patch? Patching _existing_ automake/autoconf files is something different. A different issue. We've gone through it at least half a dozen times on several lists before. If you need to patch a Makefile.am/configure.in/acinclude.m4 or other file, which in turn results in the need to regnerate the auto* files, there are two ways to achieve it: [1] Add the necessary BuildRequires (libtool -> automake -> autoconf), provided that you have compatible versions (or the older compatibility packages like automake16,...) and run them as necessary in %prep or %build. Be aware that the added dependency on these tools can break the src.rpm at an unexpected point of time. [2] Use the auto* tools to create a complete patch against the source tarball, which usually will be of around 200 KiB in _compressed_ size (even if you remove unneeded autom4te.cache files), and apply this patch inside the spec file. This moves the dependency on libtool/auto* out of the src.rpm, as you only need the tools when you create the patch. A drawback of this method is that would need to recreate the patch each time you do a version upgrade as long as upstream has not merged your changes. Note that when you run into problems rebuilding the auto* files for the patch, you could not run the tools inside %prep either, so method [1] would not work either. Personally, I prefer [2] as I don't want to regenerate auto* files more often than necessary, although the size of the patch increases small src.rpm packages significantly. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.11-1.14_FC3 loadavg: 1.82 2.00 1.69 From mricon at gmail.com Tue Apr 26 20:39:39 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Tue, 26 Apr 2005 16:39:39 -0400 Subject: Cosponsor needed: pylint Message-ID: Hello, all: I've reworked pylint and python-logilab-common packages significantly, so they should be Much Better(tm). See http://phy.duke.edu/~icon/misc/fedora-extras/. Would anyone like to co-sponsor me to add them to extras? Give me a nod and I'll import them. Cheers, -- Konstantin Ryabitsev Zlotniks, INC From smooge at gmail.com Tue Apr 26 21:02:10 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 26 Apr 2005 15:02:10 -0600 Subject: Wiki RPM In-Reply-To: <20050419174017.276ce8e7@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <1111089189.24344.13.camel@cutter> <20050414085043.3f6831c3@python2> <200504152352.55085.symbiont@berlios.de> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> Message-ID: <80d7e4090504261402f3debd0@mail.gmail.com> Sorry my paying job has taken up 60 hour weeks for the last couple of months and I should have said so. Sorry Matthias and everyone else. If anyone knows of any Unix jobs in Abq, NM let me know :).. it will probably cut down my current workload. On 4/19/05, Matthias Saou wrote: > Stephen J. Smoogen wrote : > > > On 4/15/05, Jeff Pitman wrote: > > > On Thursday 14 April 2005 14:50, Matthias Saou wrote: > I'm getting really desperate for a MoinMoin package, so I may very well > adapt Jeff's rpm. I tried rebuilding it, but always get : "error: option -- > record-rpm not recognized" on FC2, FC3 & FC Dev. > > Jeff: Is this some option added in your python packages? Is it maybe > provided by a module not listed as a build requirement? > > Matthias > -- Stephen J Smoogen. CSIRT/Linux System Administrator From ed at eh3.com Tue Apr 26 21:05:54 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 26 Apr 2005 17:05:54 -0400 Subject: Request for Review: hula In-Reply-To: <20050426214541.2ef0f6a2.bugs.michael@gmx.net> References: <200504152033.23317.hula-kevin@iprone.com> <20050416113846.4c8d83cd.bugs.michael@gmx.net> <426E875E.8060908@iprone.com> <20050426203823.23ad12cd.bugs.michael@gmx.net> <1114541212.30547.10.camel@ernie> <20050426214541.2ef0f6a2.bugs.michael@gmx.net> Message-ID: <1114549554.30547.49.camel@ernie> On Tue, 2005-04-26 at 21:45 +0200, Michael Schwendt wrote: > We've gone through it at least half a dozen times on several lists > before. If you need to patch a Makefile.am/configure.in/acinclude.m4 or > other file, which in turn results in the need to regnerate the auto* > files, there are two ways to achieve it: Hi Michael, Sorry to re-hash an old topic. And thanks for the clear explanation! I think it would be cool if someone with wiki edit permissions could (please!) add Michael's description to it: http://fedoraproject.org/wiki/PackagingGuidelines or perhaps just linked from within it? 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 ivazquez at ivazquez.net Tue Apr 26 23:05:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 26 Apr 2005 19:05:38 -0400 Subject: New Package Process (was: Re: Review Request: inadyn) In-Reply-To: <20050426135322.754a1d2d.bugs.michael@gmx.net> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> Message-ID: <1114556738.7784.90.camel@ignacio.ignacio.lan> On Tue, 2005-04-26 at 13:53 +0200, Michael Schwendt wrote: > On Tue, 26 Apr 2005 07:40:50 -0400, Ignacio Vazquez-Abrams wrote: > > > It doesn't say in the wiki that the sponsor and the reviewer have to be > > the same person. If this should be so then it might be prudent to spell > > it out. > > What does it mean "to be a package sponsor"? What are a package > sponsor's obligations? I think that the two paragraphs you wrote covers it quite well. The important question is what sort of timespan should be allowed for other contributors to chime in. One week? 2 weeks? One month? People have lives outside of Fedora Extras (supposedly), and so can't always respond to the initial commits promptly. -- 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 wtogami at redhat.com Wed Apr 27 03:03:25 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 26 Apr 2005 17:03:25 -1000 Subject: New Package Process In-Reply-To: <1114556738.7784.90.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> Message-ID: <426F00FD.2010505@redhat.com> Before reading the many messages in this thread, I need to state this: NewPackageProcess was never meant to have a separate "sponsor" and "review" during the package adding process. Sponsor was to be referred to only for what is necessary to get a CVS account, and "review" is the process by which a package becomes approved. A package must be approved explicitly by a reviewer. Many people have confused this to mean "whoever submitted a review can be listed in the APPROVED mail". It does not really matter if CVS import happens before review and revisions or after, as long as an explicit approval is made before it is built. The original NewPackageProcess allowed cvs import before review because it makes it easier to review and revise if it is in CVS. If the wording in NewPackageProcess is ambiguous it should be fixed to make all of this clear. This process however we are trying to replace with the database driven process, but that keeps getting held back due to being too busy with other things. I personally will have time to design it probably later this week after FC4test3 is frozen. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Wed Apr 27 03:23:18 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 26 Apr 2005 23:23:18 -0400 Subject: New Package Process In-Reply-To: <426F00FD.2010505@redhat.com> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> Message-ID: <20050427032318.GA14556@jadzia.bu.edu> On Tue, Apr 26, 2005 at 05:03:25PM -1000, Warren Togami wrote: > This process however we are trying to replace with the database driven > process, but that keeps getting held back due to being too busy with > other things. I personally will have time to design it probably later > this week after FC4test3 is frozen. Thanks for the clarification (gives me something to do!) and for your work on the database system -- sounds like it'll help a lot. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From ivazquez at ivazquez.net Wed Apr 27 03:39:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 26 Apr 2005 23:39:27 -0400 Subject: New Package Process In-Reply-To: <426F00FD.2010505@redhat.com> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> Message-ID: <1114573167.7784.101.camel@ignacio.ignacio.lan> On Tue, 2005-04-26 at 17:03 -1000, Warren Togami wrote: > Before reading the many messages in this thread, I need to state this: > > NewPackageProcess was never meant to have a separate "sponsor" and > "review" during the package adding process. Sponsor was to be referred > to only for what is necessary to get a CVS account, and "review" is the > process by which a package becomes approved. So then what's necessary to get a package into CVS? Other than a CVS account, of course. > This process however we are trying to replace with the database driven > process, but that keeps getting held back due to being too busy with > other things. I personally will have time to design it probably later > this week after FC4test3 is frozen. If you want/need any help then feel free to ask. I have years of experience architecting/writing database-oriented apps. -- 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 Wed Apr 27 08:34:49 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 27 Apr 2005 16:34:49 +0800 Subject: Wiki RPM In-Reply-To: <20050419174017.276ce8e7@python2> References: <80d7e40905031710101af0c9b2@mail.gmail.com> <80d7e409050418134033260a3c@mail.gmail.com> <20050419174017.276ce8e7@python2> Message-ID: <200504271634.49367.symbiont@berlios.de> On Tuesday 19 April 2005 23:40, Matthias Saou wrote: | I'm getting really desperate for a MoinMoin package, so I may very | well adapt Jeff's rpm. I tried rebuilding it, but always get : | "error: option -- record-rpm not recognized" on FC2, FC3 & FC Dev. | | Jeff: Is this some option added in your python packages? Is it maybe | provided by a module not listed as a build requirement? https://www.redhat.com/archives/fedora-extras-list/2005-March/msg01099.html It was an experimental option I added to demonstrate inclusion of %dir and %lang types inside of the file list so the --record concept would actually be useful w.r.t. RPM building. I've been moving away from it in newer builds to become compatible with Python's outside of PyVault. -- -jeff ps. Sorry for the late reply. Looks like you've got things handled. From bugs.michael at gmx.net Wed Apr 27 10:03:47 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Apr 2005 12:03:47 +0200 Subject: New Package Process In-Reply-To: <426F00FD.2010505@redhat.com> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> Message-ID: <20050427120347.41cfd346.bugs.michael@gmx.net> On Tue, 26 Apr 2005 17:03:25 -1000, Warren Togami wrote: > Before reading the many messages in this thread, I need to state this: > > NewPackageProcess was never meant to have a separate "sponsor" and > "review" during the package adding process. Sponsor was to be referred > to only for what is necessary to get a CVS account, and "review" is the > process by which a package becomes approved. No, the page explicitly refers to somebody to "sponsor your package" and even uses the term "package sponsor". Hence there are requests for packages to be sponsored. And these requests come also from contributors, who are sponsored, but think they need a package specific sponsor according to the process. In fact, they only need [at least] a single reviewer from the list of approved contributors, who adds another pair of eyes and approves a package. Whether other reviewers add post-commit comments is a side-effect of the process. > A package must be approved explicitly by a reviewer. Many people have > confused this to mean "whoever submitted a review can be listed in the > APPROVED mail". Which is what I've pointed out before. Comments on CVS diffs usually don't do the important steps of a real review as outlined before (security relevant checks, set-up/config/dep verification, test-building). Based on reading just a spec file, it's possible to find mistakes too, though, or give hints. > It does not really matter if CVS import happens before > review and revisions or after, as long as an explicit approval is made > before it is built. Except, it doesn't make much sense to important something without review only to find out that there are legal issues or it doesn't build due to missing requirements (not included in Fedora Extras) or needs much work packaging/run-time wise. From wtogami at redhat.com Wed Apr 27 10:17:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 27 Apr 2005 00:17:53 -1000 Subject: New Package Process In-Reply-To: <20050427120347.41cfd346.bugs.michael@gmx.net> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> Message-ID: <426F66D1.6070502@redhat.com> Michael Schwendt wrote: >>It does not really matter if CVS import happens before >>review and revisions or after, as long as an explicit approval is made >>before it is built. > > > Except, it doesn't make much sense to important something without review > only to find out that there are legal issues or it doesn't build due to > missing requirements (not included in Fedora Extras) or needs much work > packaging/run-time wise. > Good reasons. Then we will disallow this in the future. For everything else please clarify in the Wiki. Warren From toshio at tiki-lounge.com Wed Apr 27 12:20:23 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 27 Apr 2005 05:20:23 -0700 Subject: New Package Process In-Reply-To: <426F66D1.6070502@redhat.com>; from wtogami@redhat.com on Wed, Apr 27, 2005 at 12:17:53AM -1000 References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> Message-ID: <20050427052023.A19722@tiki-lounge.com> On Wed, Apr 27, 2005 at 12:17:53AM -1000, Warren Togami wrote: > Michael Schwendt wrote: > >>It does not really matter if CVS import happens before > >>review and revisions or after, as long as an explicit approval is made > >>before it is built. > > > > > > Except, it doesn't make much sense to important something without review > > only to find out that there are legal issues or it doesn't build due to > > missing requirements (not included in Fedora Extras) or needs much work > > packaging/run-time wise. > > > > Good reasons. Then we will disallow this in the future. For everything > else please clarify in the Wiki. > Not disagreeing but there needs to be some "Well-behavedness" guidelines so we know what is expected of a package to be put into CVS. Here's my start for a list: * Follows naming guidelines * No one raises any legal issues * Passes security checks for upstream pristine sources * Passes security checks in spec file build/install scripts - Unfortunately this means someone does need to skim through the spec. * Patches don't look malicious - Unfortunately this means someone has to review the patches. * Packager shows commitment to fix issues raised We end up needing to do a pretty thorough review before package import -- just not blocking cvs import on all the things that are found.... Someone else have some better ideas? -Toshio From mpeters at mac.com Wed Apr 27 12:29:27 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 27 Apr 2005 05:29:27 -0700 Subject: libvisual (and question about gstreamer-plugins) In-Reply-To: <1114514177.7831.8.camel@fc4t2.mpeters.local> References: <1114433969.1438.8.camel@fc4t2.mpeters.local> <1114514177.7831.8.camel@fc4t2.mpeters.local> Message-ID: <1114604967.11644.11.camel@fc4t2.mpeters.local> On Tue, 2005-04-26 at 04:16 -0700, Michael A. Peters wrote: > > There is a hitch with it - it libvisual-plugins package does not compile > with gcc4. Problem solved. Only one plugin (infinite) has a problem with gcc4. So this weekend I'll clean up my spec file and submit it for review. -=- I also will want to submit a specfile for gstreamer-plugins-libvisual I'm building it using the "patent cleansed" gstreamer-plugins tarball from the rawhide gstreamer-plugins src.rpm AFAIK there is no full path url to use for source0. Is it OK to indicate in the spec file that the sources Source0: gst-plugins-%{version}.patched.tar.bz2 Source2: patch-tarball.sh Source3: removed-sources.txt come from the fedora rawhide src.rpm as far as upstream md5sum checking? The gstreamer-plugins-libvisual package gives immediate benefit to totem, I am not aware of any other applications that can use the plugin (at least that ship with Fedora) - but it's nice to use in totem. From bugs.michael at gmx.net Wed Apr 27 12:44:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Apr 2005 14:44:48 +0200 Subject: libvisual (and question about gstreamer-plugins) In-Reply-To: <1114604967.11644.11.camel@fc4t2.mpeters.local> References: <1114433969.1438.8.camel@fc4t2.mpeters.local> <1114514177.7831.8.camel@fc4t2.mpeters.local> <1114604967.11644.11.camel@fc4t2.mpeters.local> Message-ID: <20050427144448.48297c60.bugs.michael@gmx.net> On Wed, 27 Apr 2005 05:29:27 -0700, Michael A. Peters wrote: > I also will want to submit a specfile for gstreamer-plugins-libvisual > > I'm building it using the "patent cleansed" gstreamer-plugins tarball > from the rawhide gstreamer-plugins src.rpm > > AFAIK there is no full path url to use for source0. > Is it OK to indicate in the spec file that the sources > > Source0: gst-plugins-%{version}.patched.tar.bz2 > Source2: patch-tarball.sh > Source3: removed-sources.txt > > come from the fedora rawhide src.rpm as far as upstream md5sum checking? Yes. And btw, if we want to scale ever, we need to learn to build up trust and rely on the individual package developers ensure painstakingly that the used source code tarballs are fine. I mean, we have a process for new packages, which require approval even for RH employees, but subsequent version upgrades [and their uploads to lookaside cache] probably are not reviewed beyond what's visible in cvs commit diffs (well, except for new contributors perhaps). From bugs.michael at gmx.net Wed Apr 27 13:23:09 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Apr 2005 15:23:09 +0200 Subject: New Package Process In-Reply-To: <20050427052023.A19722@tiki-lounge.com> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427052023.A19722@tiki-lounge.com> Message-ID: <20050427152309.56eec4d6.bugs.michael@gmx.net> On Wed, 27 Apr 2005 05:20:23 -0700, Toshio Kuratomi wrote: > Not disagreeing but there needs to be some "Well-behavedness" guidelines so > we know what is expected of a package to be put into CVS. > > Here's my start for a list: > * Follows naming guidelines > * No one raises any legal issues > * Passes security checks for upstream pristine sources > * Passes security checks in spec file build/install scripts > - Unfortunately this means someone does need to skim through the spec. > * Patches don't look malicious > - Unfortunately this means someone has to review the patches. > * Packager shows commitment to fix issues raised The last item being the most important one, most likely. If there's disagreement on how to package something (e.g. file locations, uids/gids and startup scripts in a non-trivial or complex package), packager and reviewer should be willing to reach an agreement. > We end up needing to do a pretty thorough review before package import -- > just not blocking cvs import on all the things that are found.... > > Someone else have some better ideas? We run into the "mandatory vs. optional" trap again. This can be seen in that you used the word "unfortunately" two times in your list. ;) With a list of things to check, the longer the list, the more it scares off reviewers _and_ package contributors. Let's compare that with fedora.us. The "QA Checklist" was made for _all_ packagers, surely not just for reviewers. A packager, who didn't consider the items on the QA checklist, didn't do his homework. A package with many issues, both major and minor, is more difficult to review than a package with only a few issues. It needs several steps to clean up a package if you don't want to rewrite it from scratch. I'd like to get back to one-step approvals of the form "reviewer examines a src.rpm and can tell in a single message what things exactly would need to be changed prior to approval". The risk, that a packager applies other changes and introduces new issues, is always there. But I want to avoid packagers asking "What else is needed?" and [probably impatient] questions. When a contributor decides to sponsor a package, he should have a good idea of whether or when the package is _ready_ and early classification of issues into "blockers" and "nitpicking/beautiful-spec-writing". I'd like to increase the learning experience, too, so reviewers ("package sponsors") send their approval as soon as they feel good about the package they reviewed, preferably as soon as the most important checks (from your list above) have been done. If we don't do this, but import unapproved packages, then review them over several days and with the help of comments on commit diffs, and only then post an approval, it doesn't become clear, who checked what. We still do have the possibility for contributors to veto something after approval, and even after build to remove something from the repository. From gdk at redhat.com Wed Apr 27 14:09:01 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Apr 2005 10:09:01 -0400 (EDT) Subject: New Package Process In-Reply-To: <426F66D1.6070502@redhat.com> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> Message-ID: My biggest problems with the review process, aside from the obvious technical issues: 1. It's not clear who should be doing the reviewing. 2. It's not clear what they're reviewing for. 3. It's not clear why review is necessary. To take these point by point: 1. WHO. This is why the bugzilla queue is so important -- it lessens the burden of answering the question "who," because if the "NeedsReview" queue is well-understood, then anybody who has spare cycles can review a package. I think that will help everyone, and as I understand it, this is the particular problem that Warren and dkl are working on now. 2. WHAT. Do we all agree what we're reviewing for? Are we reviewing for adherence to the packaging guidelines? Are there hard criteria that can be tested by tools, or are we simply looking for "little things" that only experienced eyes can spot? 3. WHY. Why are reviewing people's packages? To teach them what's good and what's bad? To teach them in matters of taste? Theoretically, a package that isn't properly assembled should fail to build -- should we be working to put some of this burden on the build system? Is that possible/feasible? === Let me sell a little bit of big picture here. How will we scale this project to a million packages? Because that's the goal. The goal of Fedora Extras, in my mind, is to provide all of the software in the world to all of the people in the world. Nothing less. Is that a ridiculous goal? Of course it is. But it's the ridiculous goal that gets me out of bed in the morning. What is the *one thing* that stands *most directly* in the way of reaching that ridiculous goal? I'd say it's the fact that there are maybe 100 people in the whole world who *really* understand how to build good RPMs -- and there are very few good tools to help. If we are ever to solve the "million packages" problem, we MUST limit the need for human review, and we MUST build the tools to help us do it. Here's the review process as it stands now: 1. Novice packager submits crap package. 2. Reviewer takes an hour to explain precisely why it's crap. 3. Novice packager fixes and submits somewhat-less-crap package. 4. Reviewer takes 15 minutes to explain why it's still a bit crap. 5. Lather, rinse, repeat until package is not at all crap. Here's how I wish the review process worked, and how I think we should aspire to having it work: 1. Novice packager builds crap package with the assistance of fe-pkg-builder. 2. Novice packager puts crap package thru fe-pkg-lint, which points out large chunks of crap. 3. Novice packager fixes package so that fe-pkg-lint doesn't puke. 4. Reviewer points out why it's still a bit crap. 5. Reviewer files bugs against fe-pkg-builder and/or fe-pkg-lint. To recap: The goal of the Fedora Extras project should NOT be to teach everyone the difficult art of building a good package. That's solving the wrong problem. The goal, rather, should be to make that difficult art as easy as possible. Otherwise, the universe of packages will *always* be limited by the number of people who are smart enough to work their way through our arcane rules -- rules which *we* should be smart enough to figure out how to hide. And yes, having discussed this problem ad nauseum with RHN engineers, I *know* how hard it is to solve. Doesn't change the fact that it *is* the problem that *must be solved*. So. How do we start? Or do we believe that it can't be done? --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From fedora at camperquake.de Wed Apr 27 14:53:50 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 27 Apr 2005 16:53:50 +0200 Subject: New Package Process In-Reply-To: References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> Message-ID: <20050427145350.GA20560@ryoko.camperquake.de> On Wed, Apr 27, 2005 at 10:09:01AM -0400, Greg DeKoenigsberg wrote: > Let me sell a little bit of big picture here. > > How will we scale this project to a million packages? Because that's the > goal. The goal of Fedora Extras, in my mind, is to provide all of the > software in the world to all of the people in the world. Nothing less. Just a litte comment: debian has been trying to do this, and has come to a screeching halt by now, failing to release a new stable version for almost three years now, and steadily trying to replace Duke Nukem Forever as the All-Time-Vaporware champion. This may not be a problem now, but will be later, especially if a) more architectures are added to FC b) failing to build on one arch is a blocker And all other things that may be said about debian nonwithstanding, they do have procedures for everything. From gdk at redhat.com Wed Apr 27 15:00:23 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Apr 2005 11:00:23 -0400 (EDT) Subject: New Package Process In-Reply-To: <20050427145350.GA20560@ryoko.camperquake.de> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> Message-ID: On Wed, 27 Apr 2005, Ralf Ertzinger wrote: > On Wed, Apr 27, 2005 at 10:09:01AM -0400, Greg DeKoenigsberg wrote: > > Just a litte comment: debian has been trying to do this, and has come > to a screeching halt by now, failing to release a new stable version > for almost three years now, and steadily trying to replace Duke Nukem > Forever as the All-Time-Vaporware champion. > > This may not be a problem now, but will be later, especially if > a) more architectures are added to FC > b) failing to build on one arch is a blocker "Failing to build on one arch = blocker": If we're going to commit to this policy, we need to ensure that every developer has access to every arch. (This will take some time, but we know it to be true.) Perhaps a policy will evolve in which we have more- and less-blessed arches; I certainly don't ever want to be in a position in which we have 200 important packages blocking because they can't build on IBM Z-Series boxes. > And all other things that may be said about debian nonwithstanding, > they do have procedures for everything. Yep. Which is good and bad. We need more policy. But not too much. :) --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From Jochen at herr-schmitt.de Wed Apr 27 15:08:51 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Apr 2005 17:08:51 +0200 Subject: Review Request: inadyn In-Reply-To: <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> Message-ID: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> On Tue, 26 Apr 2005 16:59:45 +0200, you wrote: >The upstream mainainer has wrote, that he wants to include a pid >handle option in the next version of inadyn. That was the reason, >why I have diced to defer a implementation of a init script after >the release of the next version. On Ignacio: It is okay, if I will write the initscript for the next version of inadyn, if it released, or it is a hard requirement to wrote the initscript. I have wrote a patch for implementation a pid handling for inadyn and sent it to the upstream maintainer. But becouse he told me, that he wants to release the next version in april, I have defered the used of this patch. The disadvancetage to write a initscript without a pid handling is, that you have kill all inady processes with 'killall inadyn' when you type # /etc/init.d/inadyn stop It will be nice to hear your mind to this topic. Best Regards: Jochen Schmitt From ivazquez at ivazquez.net Wed Apr 27 15:15:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Apr 2005 11:15:16 -0400 Subject: Review Request: inadyn In-Reply-To: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> Message-ID: <1114614916.5061.12.camel@ignacio.ignacio.lan> On Wed, 2005-04-27 at 17:08 +0200, Jochen Schmitt wrote: > The disadvancetage to write a initscript without a pid handling > is, that you have kill all inady processes with 'killall inadyn' > when you type > > # /etc/init.d/inadyn stop > > It will be nice to hear your mind to this topic. That's what $! in bash is for. Just capture the PID via that and send it to a 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 Jochen at herr-schmitt.de Wed Apr 27 15:17:42 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Apr 2005 17:17:42 +0200 Subject: New Package Process In-Reply-To: <20050427145350.GA20560@ryoko.camperquake.de> References: <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> Message-ID: On Wed, 27 Apr 2005 16:53:50 +0200, you wrote: >Just a litte comment: debian has been trying to do this, and has come >to a screeching halt by now, failing to release a new stable version Other Reasons for the debian problems are: Tthe fundamental discussion about GNU FDL, binary firmwares and naming convention for ia64 archs. The great number of different arch. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Wed Apr 27 15:17:43 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Apr 2005 17:17:43 +0200 Subject: New Package Process In-Reply-To: References: <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> Message-ID: On Wed, 27 Apr 2005 11:00:23 -0400 (EDT), you wrote: >don't ever want to be in a position in which we have 200 important >packages blocking because they can't build on IBM Z-Series boxes. Not every package make sense for every arch. For example: Can you show me a z/Series system with a CD/RW burner. You see, it make no sense to build k3b for the z/Series arch. A other problem is, that a lot of developers has access to i386 archs, but only few has access to Linux on z/Series systems. Best Regards: Jochen Schmitt From bugs.michael at gmx.net Wed Apr 27 15:30:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Apr 2005 17:30:19 +0200 Subject: New Package Process In-Reply-To: References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> Message-ID: <20050427173019.6ef17a36.bugs.michael@gmx.net> On Wed, 27 Apr 2005 11:00:23 -0400 (EDT), Greg DeKoenigsberg wrote: > "Failing to build on one arch = blocker": If we're going to commit to this > policy, we need to ensure that every developer has access to every arch. And even then, you expect volunteer packagers to spend time on debugging problems with architectures they don't have interest in. Often such problems are the result of the upstream developers doing development and testing for only a specific architecture. I would really prefer if "architecture specific Fedora community developers" filled the role of package co-maintainers. Else we would play the "if it builds, publish it" game and offer something, which has not been tested at all. From bugs.michael at gmx.net Wed Apr 27 15:32:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 27 Apr 2005 17:32:34 +0200 Subject: Review Request: inadyn In-Reply-To: <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> Message-ID: <20050427173234.17aa8e91.bugs.michael@gmx.net> On Wed, 27 Apr 2005 17:08:51 +0200, Jochen Schmitt wrote: > The disadvancetage to write a initscript without a pid handling > is, that you have kill all inady processes with 'killall inadyn' > when you type > > # /etc/init.d/inadyn stop "/sbin/pidof inadyn" won't work in there? From gdk at redhat.com Wed Apr 27 15:45:00 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Apr 2005 11:45:00 -0400 (EDT) Subject: New Package Process In-Reply-To: <20050427173019.6ef17a36.bugs.michael@gmx.net> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> Message-ID: On Wed, 27 Apr 2005, Michael Schwendt wrote: > I would really prefer if "architecture specific Fedora community > developers" filled the role of package co-maintainers. Else we would play > the "if it builds, publish it" game and offer something, which has not > been tested at all. Which is potentially bad, I agree -- but not guaranteed bad. Let's play this game. I'll present a scenario, and everyone pile on and tell me what's wrong with it. 1. A *very* lightweight *initial* package acceptance process, in which we determine: a. No obvious maliciousness; b. No obvious IP/copyright issues. 2. A policy of "build the world". Every package in the build system, we build. If it passes, it goes into the "untested" bucket. This bucket is also a repo, for those who dare. 3. A mechanism for "final review" that marks the difference between "a package that builds" and "a package the builds and is any good". And let's think creatively about this final review: does it need to be a single person who says "this is ok, I bless it"? Or could it *also* be a threshhold? For example: we could say that any package that is installed 100 times from the untested repo, without anyone voting against it, is automatically promoted to the "tested" bucket. This would provide two paths: one path for packages that people are watching over, and a parallel path for packages that people aren't watching over, but are still using. Is this foolish or wrong in any way? --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From fedora at leemhuis.info Wed Apr 27 16:20:55 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 27 Apr 2005 18:20:55 +0200 Subject: New Package Process In-Reply-To: <20050427173019.6ef17a36.bugs.michael@gmx.net> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> Message-ID: <1114618855.5373.22.camel@notebook.thl.home> Am Mittwoch, den 27.04.2005, 17:30 +0200 schrieb Michael Schwendt: > On Wed, 27 Apr 2005 11:00:23 -0400 (EDT), Greg DeKoenigsberg wrote: > > > "Failing to build on one arch = blocker": If we're going to commit to this > > policy, we need to ensure that every developer has access to every arch. > > And even then, you expect volunteer packagers to spend time on debugging > problems with architectures they don't have interest in. And even is they had, I still suspect that all volunteer packagers have enough knowledge to fix packages on all those archs (I, for example, don't have that that much programming experience to do this). > [...] > I would really prefer if "architecture specific Fedora community > developers" filled the role of package co-maintainers. ++ And even more: If one package does not get fixed in lets say around (4| 7|10|14|"your vote here") days, publish it for the other archs if it does no other real harm for the project. > Else we would play > the "if it builds, publish it" game and offer something, which has not > been tested at all. Well, testing the important packages might be possible. But I suspect "architecture specific Fedora community developers" can test all releases and updates of Gregs "... we scale this project to a million packages? Because that's the goal". Maybe we should use the testing-repo more. Verified packages could get moved to the normal repo after 4 (or maybe 7) days, unverified packages will get moved automatically after 28 days (for example). Just my 2 cent -- Thorsten Leemhuis From fedora at camperquake.de Wed Apr 27 16:44:47 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 27 Apr 2005 18:44:47 +0200 Subject: New Package Process In-Reply-To: References: <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> Message-ID: <20050427184447.7402434f@nausicaa.camperquake.de> Hi. Jochen Schmitt wrote: > For example: Can you show me a z/Series system with a CD/RW > burner. You see, it make no sense to build k3b for the z/Series > arch. Don't these things have SCSI? Honestly, I have never had my hands on one. -- Confucius say, "Man who quote me is fool." From Jochen at herr-schmitt.de Wed Apr 27 17:15:18 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Apr 2005 19:15:18 +0200 Subject: Review Request: inadyn In-Reply-To: <1114614916.5061.12.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> Message-ID: On Wed, 27 Apr 2005 11:15:16 -0400, you wrote: >That's what $! in bash is for. Just capture the PID via that and send it >to a file. I have try it, and it seems, it didn't work. I have wrote a initscript without capturing of the PID and have checked in the CVS. Best Regards: Jochen Schmitt From sopwith at redhat.com Wed Apr 27 17:16:32 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 27 Apr 2005 13:16:32 -0400 (EDT) Subject: New Package Process In-Reply-To: <20050427184447.7402434f@nausicaa.camperquake.de> References: <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427184447.7402434f@nausicaa.camperquake.de> Message-ID: On Wed, 27 Apr 2005, Ralf Ertzinger wrote: > > For example: Can you show me a z/Series system with a CD/RW > > burner. You see, it make no sense to build k3b for the z/Series > > arch. > > Don't these things have SCSI? Honestly, I have never had my hands on > one. Dude, z/Series is a mainframe in two refrigerator cabinets, with a separate OS/2 computer sitting on your desk just to manage the thing. Even the FC SCSI connection they have is going to be connected to a $500k Shark storage array ;-) s390 & s390x don't have anything in the way of typical end-user hardware. Best, -- Elliot From rc040203 at freenet.de Wed Apr 27 17:17:31 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Apr 2005 19:17:31 +0200 Subject: New Package Process In-Reply-To: References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> Message-ID: <1114622252.24385.134.camel@mccallum.corsepiu.local> On Wed, 2005-04-27 at 11:45 -0400, Greg DeKoenigsberg wrote: > On Wed, 27 Apr 2005, Michael Schwendt wrote: > > > I would really prefer if "architecture specific Fedora community > > developers" filled the role of package co-maintainers. Else we would play > > the "if it builds, publish it" game and offer something, which has not > > been tested at all. > > Which is potentially bad, I agree -- but not guaranteed bad. > > Let's play this game. I'll present a scenario, and everyone pile on and > tell me what's wrong with it. > > 1. A *very* lightweight *initial* package acceptance process, in which we > determine: > a. No obvious maliciousness; > b. No obvious IP/copyright issues. > > 2. A policy of "build the world". Every package in the build system, we > build. If it passes, it goes into the "untested" bucket. This bucket > is also a repo, for those who dare. > > 3. A mechanism for "final review" that marks the difference between "a > package that builds" and "a package the builds and is any good". Excellent, I was about to write almost the same when your mail arrived :-) Some considerations, which IMO hasn't had enough attention so far: * I don't see a need why packages need to be maintained by single individuals, they should be maintained by collaborating maintainers. i.e. I am opposed to "package sponsoring" and to "assigning packages" to individuals, because this doesn't encourage collaboration. * reviews should have as "many eyes" as possible. IMO, fedora.us has demonstrated that bugzilla is well suited to maintaining a package's state, but is not suitable a main tool for package reviews. * How about post-release QA? Bug reporting or (in worst case) even package withdrawal requests? > And > let's think creatively about this final review: does it need to be a > single person who says "this is ok, I bless it"? I am in favor of a "voting system", e.g. a system that requires several "ready for release" votes before a package can be released. It would help prevent cases of individuals "pushing something half-bred through" - Cases not 100% free of this suspicion had happened on fedora.us (Of cause everybody will deny this allegation ;-) ) > Or could it *also* be a > threshhold? > For example: we could say that any package that is installed > 100 times from the untested repo, without anyone voting against it, > is automatically promoted to the "tested" bucket. Well, this criterion has very little significance. Firstly, the number of installs/downloads doesn't mean much, secondly, not all packages are of equal interest/have the same size of audience. > This would provide two > paths: one path for packages that people are watching over, and a parallel > path for packages that people aren't watching over, but are still using. > > Is this foolish or wrong in any way? Do you mean having a repo of unreleased/testing/prerelease packages and one of "officially released" packages? This would make sense. Ralf From Jochen at herr-schmitt.de Wed Apr 27 17:24:46 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 Apr 2005 19:24:46 +0200 Subject: Status fedora-extras-commits mailings Message-ID: <0ML21M-1DQqHH2Lof-0003eg@mrelayeu.kundenserver.de> Hello, I have commit a few changes of my packages to CVS in the last hour. But I didn't got any mailing since last evening. Even the mailling list archive didn't contains any mail which is younger the the last mail I recieve. Are there any known problem with the CVS mailing? Best Regards: Jochen Schmitt From j.w.r.degoede at hhs.nl Wed Apr 27 15:11:19 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 27 Apr 2005 17:11:19 +0200 Subject: Review request: Glide3 Message-ID: <426FAB97.2000302@hhs.nl> Hi, I've been busy creating a new Glide3 package for FE for FC4, since Glide3 will be dropped from core. This package is based on the Glide3 core CVS tree for FC-2, this because some earlier fixes of mine were committed to Fedora-Core CVS FC-2 instead of FC-3/devel by accident. FC2 contained a release of 34 and FC-3 and devel of 33. Although AFAIK the FC-2 34 release in CVS was nevewr build (because comitted to the wrong branch) I've made the new release tag 35 just to be sure. The 2 main changes to this package form FC-2 CVS are a patch which is nescesarry to compile this with gcc4 and some specfile cleanups to better match most FE specfiles. I haven't imported this into CVS yet, because I don't have the proper ssh cert on the PC I'm typing this on :) In the meanwhile you can take a look at the SRPM, point your browser at: http://jwrdegoede.freesuperhost.com/ And then follow the SRPMS link. I can't give you a direct link because of the freehosting service, sorry about that, but my ISP has given me plenty quota, but doesn't allow files larger then 1 Mb (GRRRR). Regards, Hans From jdennis at redhat.com Wed Apr 27 17:46:59 2005 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Apr 2005 13:46:59 -0400 Subject: New Package Process In-Reply-To: <1114622252.24385.134.camel@mccallum.corsepiu.local> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> Message-ID: <1114624019.16696.41.camel@finch.boston.redhat.com> On Wed, 2005-04-27 at 19:17 +0200, Ralf Corsepius wrote: > Some considerations, which IMO hasn't had enough attention so far: > * I don't see a need why packages need to be maintained by single > individuals, they should be maintained by collaborating maintainers. > i.e. I am opposed to "package sponsoring" and to "assigning packages" to > individuals, because this doesn't encourage collaboration. Collaboration or shared responsibility is a good thing, but if and only if, the people changing a package in CVS are members of an approved group of people for that package, e.g. a maintenance team, otherwise this is a recipe for disaster. Embodied in the concept of a maintainer is a person that has unique knowledge of that package, a history of why things were done a certain way, what is happening upstream, what is the relationship to other packages, what is happening the in maintainers local work area, etc. If you allow random people to make random changes its going to create problems. However, I do like the idea of a maintenance "team" that avoids revision anarchy. -- John Dennis From mccabemt at gmail.com Wed Apr 27 16:58:27 2005 From: mccabemt at gmail.com (Michael McCabe) Date: Wed, 27 Apr 2005 12:58:27 -0400 Subject: New Package Process In-Reply-To: <20050427184447.7402434f@nausicaa.camperquake.de> References: <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427184447.7402434f@nausicaa.camperquake.de> Message-ID: <1114621107.3541.5.camel@thebeast> I'm pretty sure with the right connection you'd be able to hookup any external SCSI devices. I'm not sure how many hobbyists can afford a z/Series though. Mike On Wed, 2005-04-27 at 18:44 +0200, Ralf Ertzinger wrote: > Hi. > > Jochen Schmitt wrote: > > > For example: Can you show me a z/Series system with a CD/RW > > burner. You see, it make no sense to build k3b for the z/Series > > arch. > > Don't these things have SCSI? Honestly, I have never had my hands on > one. > From sopwith at redhat.com Wed Apr 27 18:47:20 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 27 Apr 2005 14:47:20 -0400 (EDT) Subject: New Package Process In-Reply-To: <1114624019.16696.41.camel@finch.boston.redhat.com> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114624019.16696.41.camel@finch.boston.redhat.com> Message-ID: You guys are overthinking this a bit too much. Practically speaking, anyone can make changes to any package by talking with and building a relationship with the package maintainer. This is not rocket science here. You want to get things done, you talk to the right people - setting up complicated policies is not necessary when having a designated maintainer is sufficient. So if you're a maintainer want to set up a maintenance team for a particular package, that's fine. Just go ahead and do it and don't ask for permission, affirmation, or whatever. The only rule we really need to manage: The steering committee or its agents designate the package maintainer. The package maintainer sets the rules for working with that package. On a slightly related note, I'm in favor of what Greg posted about keeping the initial package review process minimal, and then encouraging an environment of constant improvement by doing ongoing QA on the packages that come out of the build system. That will make it easier for people to learn how to do good packaging, and also focus our package review efforts on the end results (i.e. QA happens on the built packages) which means integration issues and end-user issues are more likely to get detected. Right now the package review is just finding .spec file style issues (Summaries that have a period at the end), while being unlikely to detect things like a package that won't work. Best, -- Elliot From enrico.scholz at informatik.tu-chemnitz.de Wed Apr 27 19:07:22 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 27 Apr 2005 21:07:22 +0200 Subject: New Package Process In-Reply-To: (Greg DeKoenigsberg's message of "Wed, 27 Apr 2005 10:09:01 -0400 (EDT)") References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> Message-ID: <87br80f385.fsf@kosh.bigo.ensc.de> gdk at redhat.com (Greg DeKoenigsberg) writes: > How will we scale this project to a million packages? I do not think that we will have millions of packages... freshmeat lists around 35000 packages and we (Core + Extras) are currently at 2000 packages. > Because that's the goal. The goal of Fedora Extras, in my mind, is to > provide all of the software in the world to all of the people in the > world. Nothing less. I would add the word 'high-quality' somewhere... Thousands of crappy packages do not help somebody and make the repository useless. > 1. Novice packager builds crap package with the assistance of > fe-pkg-builder. > 2. Novice packager puts crap package thru fe-pkg-lint, which points out > large chunks of crap. Where can I download fe-pkg-lint? ;) IMO, you can detect only a small class of errors by automatic tests, real QA needs human intervention. 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 Wed Apr 27 18:57:26 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 27 Apr 2005 20:57:26 +0200 Subject: New Package Process In-Reply-To: <1114622252.24385.134.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 27 Apr 2005 19:17:31 +0200") References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> Message-ID: <87fyxcf3op.fsf@kosh.bigo.ensc.de> rc040203 at freenet.de (Ralf Corsepius) writes: > * How about post-release QA? Bug reporting or (in worst case) even > package withdrawal requests? Fedora Core shows that post-release QA does not work. Bugreports will be ignored and stay forever as most packagers are busy. With an everybody-can-publish policy for Fedora Extras, I fear that we will end in a RH contrib style repository where 80% of packages are broken. >> And let's think creatively about this final review: does it need to >> be a single person who says "this is ok, I bless it"? > I am in favor of a "voting system", e.g. a system that requires several > "ready for release" votes before a package can be released. Such a thing exists already... See http://enrico-scholz.de/diplom/main-DE-oneside.pdf, section 4.9. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From sopwith at redhat.com Wed Apr 27 19:10:19 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 27 Apr 2005 15:10:19 -0400 (EDT) Subject: New Package Process In-Reply-To: <1114622252.24385.134.camel@mccallum.corsepiu.local> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> Message-ID: On Wed, 27 Apr 2005, Ralf Corsepius wrote: > Some considerations, which IMO hasn't had enough attention so far: > * I don't see a need why packages need to be maintained by single > individuals, they should be maintained by collaborating maintainers. That can happen, but it has to happen because We /have/ to have someone who is ultimately held accountable for making the package work. That's all the package maintainer is. How they get the work done (by themselves, through collaboration, etc.) is up to them. I agree that encouraging collaboration is good, but that needs to be done without compromising the leadership function of the maintainer. Best, -- Elliot From laroche at redhat.com Wed Apr 27 19:18:06 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 27 Apr 2005 21:18:06 +0200 Subject: New Package Process In-Reply-To: References: <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> Message-ID: <20050427191806.GA3713@dudweiler.stuttgart.redhat.com> On Wed, Apr 27, 2005 at 03:10:19PM -0400, Elliot Lee wrote: > On Wed, 27 Apr 2005, Ralf Corsepius wrote: > > > Some considerations, which IMO hasn't had enough attention so far: > > * I don't see a need why packages need to be maintained by single > > individuals, they should be maintained by collaborating maintainers. > > That can happen, but it has to happen because > > We /have/ to have someone who is ultimately held accountable for making > the package work. That's all the package maintainer is. How they get the > work done (by themselves, through collaboration, etc.) is up to them. I > agree that encouraging collaboration is good, but that needs to be done > without compromising the leadership function of the maintainer. I think we should add a second group of core developers who can also add patches to all packages they feel confident. Put in a four-day warning period and this should be pretty effective. Seth needed this for startup and the same item will keep coming up during further development. greetings, Florian La Roche From laroche at redhat.com Wed Apr 27 19:20:38 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 27 Apr 2005 21:20:38 +0200 Subject: New Package Process In-Reply-To: References: <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114624019.16696.41.camel@finch.boston.redhat.com> Message-ID: <20050427192038.GB3713@dudweiler.stuttgart.redhat.com> > Practically speaking, anyone can make changes to any package by talking > with and building a relationship with the package maintainer. This is not At least for a devel cycle we should be even more open. Otherwise small improvements are often not done at all. Just look at todays rawhide report and ask Jeremy why he didn't leave a one-line change in 15 packages up to the individual maintainers to finish off. greetings, Florian La Roche From jdennis at redhat.com Wed Apr 27 19:24:25 2005 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Apr 2005 15:24:25 -0400 Subject: New Package Process In-Reply-To: References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> Message-ID: <1114629865.16696.53.camel@finch.boston.redhat.com> On Wed, 2005-04-27 at 15:10 -0400, Elliot Lee wrote: > We /have/ to have someone who is ultimately held accountable for making > the package work. That's all the package maintainer is. Who is going to want to be held accountable for changes they didn't make or approve? -- John Dennis From jdennis at redhat.com Wed Apr 27 19:30:06 2005 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Apr 2005 15:30:06 -0400 Subject: New Package Process In-Reply-To: <20050427192038.GB3713@dudweiler.stuttgart.redhat.com> References: <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114624019.16696.41.camel@finch.boston.redhat.com> <20050427192038.GB3713@dudweiler.stuttgart.redhat.com> Message-ID: <1114630206.16696.57.camel@finch.boston.redhat.com> On Wed, 2005-04-27 at 21:20 +0200, Florian La Roche wrote: > > Practically speaking, anyone can make changes to any package by talking > > with and building a relationship with the package maintainer. This is not > > At least for a devel cycle we should be even more open. Otherwise small > improvements are often not done at all. > Just look at todays rawhide report and ask Jeremy why he didn't leave a > one-line change in 15 packages up to the individual maintainers to finish > off. The concept of a very small highly trusted group that has the authority to alter every package is necessary. There are some circumstances that demand this, but that not the same as opening packages up for modification by the general community. -- John Dennis From gdk at redhat.com Wed Apr 27 19:39:18 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Apr 2005 15:39:18 -0400 (EDT) Subject: New Package Process In-Reply-To: <87br80f385.fsf@kosh.bigo.ensc.de> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <87br80f385.fsf@kosh.bigo.ensc.de> Message-ID: On Wed, 27 Apr 2005, Enrico Scholz wrote: > gdk at redhat.com (Greg DeKoenigsberg) writes: > > > How will we scale this project to a million packages? > > I do not think that we will have millions of packages... freshmeat > lists around 35000 packages and we (Core + Extras) are currently at > 2000 packages. s/million/bazillion or any arbitrarily large number. I certainly don't intend to be didactic. > > Because that's the goal. The goal of Fedora Extras, in my mind, is to > > provide all of the software in the world to all of the people in the > > world. Nothing less. > > I would add the word 'high-quality' somewhere... Thousands of crappy > packages do not help somebody and make the repository useless. You know, that *sounds* like a good argument, but on further reflection, I don't *actually* think that's true. Is Sourceforge any less useful because there are thousands of poorly-maintained projects? No, it isn't. Sourceforge excels because it gives users all of the info they need about those projects, so that they make make their own determinations about projects are, or aren't, "high-quality". I agree with this statement: a pile of undifferentiated packages, some of which are crap and some of which aren't, is bad. But that doesn't have to be the way we do it. > > 1. Novice packager builds crap package with the assistance of > > fe-pkg-builder. > > 2. Novice packager puts crap package thru fe-pkg-lint, which points out > > large chunks of crap. > > Where can I download fe-pkg-lint? ;) IMO, you can detect only a small > class of errors by automatic tests, real QA needs human intervention. It's a continuum. QA tools can never fully replace human QA. In the short term, you may (or may not) be right when you say that automatic tests can only detect a small class of errors. In the long term, though, a good tool can grow to handle a large number of cases, and we really do need to start *somewhere*, don't we? And as far as where you can go to download fe-pkg-lint, of course the answer is that we have to write it, and we have to mandate its use, and we have to commit to making it more useful over time. Standard disclaimer: I could, as always, be completely wrong. --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From ed at eh3.com Wed Apr 27 19:40:08 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 27 Apr 2005 15:40:08 -0400 Subject: New Package Process In-Reply-To: References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> Message-ID: <1114630808.6220.65.camel@ernie> On Wed, 2005-04-27 at 15:10 -0400, Elliot Lee wrote: > > We /have/ to have someone who is ultimately held accountable for making > the package work. That's all the package maintainer is. How they get the > work done (by themselves, through collaboration, etc.) is up to them. I > agree that encouraging collaboration is good, but that needs to be done > without compromising the leadership function of the maintainer. Yeah, this seems fundamental. So, to keep some level of quality in the process (creating packages that almost all work), does it follow that: - a maintainer can only properly handle so many packages and so many reviews of others' packages - lint-like tools and all-around better automation can help but they simply *cannot* replace attentive and clue-full reviewers and maintainers - to scale, new maintainers will *need* to be trained and this training process probably deserves as much attention as the automated tools, etc. Or am I way off-base? Ed ps - As a packaging newbie, I can attest that the documentation for packaging is damn sparse. And I made a huge mistake by not spending enough time reading all the existing spec files which, in retrospect, is perhaps the best way to see how things can (or ought to be) done. -- 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 sopwith at redhat.com Wed Apr 27 19:55:02 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 27 Apr 2005 15:55:02 -0400 (EDT) Subject: New Package Process In-Reply-To: <1114629865.16696.53.camel@finch.boston.redhat.com> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114629865.16696.53.camel@finch.boston.redhat.com> Message-ID: On Wed, 27 Apr 2005, John Dennis wrote: > On Wed, 2005-04-27 at 15:10 -0400, Elliot Lee wrote: > > We /have/ to have someone who is ultimately held accountable for making > > the package work. That's all the package maintainer is. > > Who is going to want to be held accountable for changes they didn't make > or approve? You make it sound like they'll go to jail if the package fails review. :) If someone checks in a change that the maintainer doesn't want, then the maintainer gets to teach that person the right way to do things, and fix the problem. Encouraging contributions means responding constructively to people's failures as well as their successes. So in other words, if you aren't willing to be accountable for the output of all the contributors to the package, you aren't the right person to be the lead maintainer for a package. There's nothing wrong with not wanting to be the leader if that's not your thing, but with the power of being leader comes the responsibility of making other contributors successful. Best, -- Elliot From gdk at redhat.com Wed Apr 27 19:58:29 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Apr 2005 15:58:29 -0400 (EDT) Subject: New Package Process In-Reply-To: <1114630808.6220.65.camel@ernie> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> Message-ID: On Wed, 27 Apr 2005, Ed Hill wrote: > Yeah, this seems fundamental. So, to keep some level of quality in the > process (creating packages that almost all work), does it follow that: > > - a maintainer can only properly handle so many packages and > so many reviews of others' packages Yep. There's probably some theoretical number "n" that represents "max packages that one clueful person can sanely review". The better the tools to help with review, though, the higher the value of "n" -- perhaps dramatically higher. > - lint-like tools and all-around better automation can help > but they simply *cannot* replace attentive and clue-full > reviewers and maintainers Agreed. > - to scale, new maintainers will *need* to be trained and > this training process probably deserves as much attention > as the automated tools, etc. > > Or am I way off-base? I don't think so. > ps - As a packaging newbie, I can attest that the documentation > for packaging is damn sparse. And I made a huge mistake by > not spending enough time reading all the existing spec files > which, in retrospect, is perhaps the best way to see how > things can (or ought to be) done. There's a baseline of documentation that already exists. For instance, I wonder how many people have read, or even know about, the Red Hat RPM Guide book. I also wonder how useful it is. How many of the folks on this list have read any RPM literature at all? --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From glen at mail.cert.ucr.edu Wed Apr 27 20:07:12 2005 From: glen at mail.cert.ucr.edu (glen at mail.cert.ucr.edu) Date: Wed, 27 Apr 2005 13:07:12 -0700 Subject: NIS server tool Message-ID: <1114632432.426ff0f0f40d4@pah.cert.ucr.edu> Hi there, So I put together a little app for configuring an NIS server, and I was hoping to get it into Fedora extras. You can check it out here by the way: http://pah.cert.ucr.edu/~glen/system-config-nis.tar.bz2 In looking at the extras site it looks like I'll need someone to sponser me before I can get my junk added to extras, and so I was hoping someone could sponser me, or at least let me know what else I need to do at this point to get my package accepted. Thanks, Glen From enrico.scholz at informatik.tu-chemnitz.de Wed Apr 27 20:18:17 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 27 Apr 2005 22:18:17 +0200 Subject: New Package Process In-Reply-To: (Greg DeKoenigsberg's message of "Wed, 27 Apr 2005 15:39:18 -0400 (EDT)") References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <87br80f385.fsf@kosh.bigo.ensc.de> Message-ID: <877jioezxy.fsf@kosh.bigo.ensc.de> gdk at redhat.com (Greg DeKoenigsberg) writes: >> > How will we scale this project to a million packages? >> >> I do not think that we will have millions of packages... freshmeat >> lists around 35000 packages and we (Core + Extras) are currently at >> 2000 packages. > > s/million/bazillion or any arbitrarily large number. I certainly don't > intend to be didactic. The range is important; millons of projects can be packaged in an industrial manner (e.g. auto-spec generators) only, while 10000-20000 packages (afaik Debian has 16000 packages currently) can be generated manually. >> > Because that's the goal. The goal of Fedora Extras, in my mind, is to >> > provide all of the software in the world to all of the people in the >> > world. Nothing less. >> >> I would add the word 'high-quality' somewhere... Thousands of crappy >> packages do not help somebody and make the repository useless. > > You know, that *sounds* like a good argument, but on further reflection, I > don't *actually* think that's true. Is Sourceforge any less useful > because there are thousands of poorly-maintained projects? On Sourceforge, poorly-maintained projects can be detected easily (e.g. do not trust a g* or k* project with a version number of 0.1). Programming applications from scratch is much more expensive than doing a quick test. But things for Fedora are different... When FE would have a high rate of crappy packages, I have to review every package which I am going to install. Often, a review is more time consuming than hacking a package From scratch so such a repository would be useless. As your next 'apt-get upgrade' could install new, untested deps, auto-update mechanisms would be very risky. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mattdm at mattdm.org Wed Apr 27 21:37:41 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 27 Apr 2005 17:37:41 -0400 Subject: New Package Process In-Reply-To: References: <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> Message-ID: <20050427213741.GA13477@jadzia.bu.edu> On Wed, Apr 27, 2005 at 03:58:29PM -0400, Greg DeKoenigsberg wrote: > There's a baseline of documentation that already exists. For instance, I > wonder how many people have read, or even know about, the Red Hat RPM > Guide book. I also wonder how useful it is. That book is fairly good. The short "Guru guide" someone posted to the main Fedora list a week or so ago is also a good starting point. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From gdk at redhat.com Wed Apr 27 21:38:05 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Apr 2005 17:38:05 -0400 (EDT) Subject: New Package Process In-Reply-To: <20050427213741.GA13477@jadzia.bu.edu> References: <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> <20050427213741.GA13477@jadzia.bu.edu> Message-ID: On Wed, 27 Apr 2005, Matthew Miller wrote: > On Wed, Apr 27, 2005 at 03:58:29PM -0400, Greg DeKoenigsberg wrote: > > There's a baseline of documentation that already exists. For instance, I > > wonder how many people have read, or even know about, the Red Hat RPM > > Guide book. I also wonder how useful it is. > > That book is fairly good. The short "Guru guide" someone posted to the > main Fedora list a week or so ago is also a good starting point. Good enough to post prominently in a gigantic FAQ entry? :) --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From ed at eh3.com Wed Apr 27 21:59:21 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 27 Apr 2005 17:59:21 -0400 Subject: New Package Process In-Reply-To: References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> Message-ID: <1114639161.6220.85.camel@ernie> On Wed, 2005-04-27 at 15:58 -0400, Greg DeKoenigsberg wrote: > There's a baseline of documentation that already exists. For instance, I > wonder how many people have read, or even know about, the Red Hat RPM > Guide book. I also wonder how useful it is. Dunno. Send me a copy and I'll send you an opinion. ;-) > How many of the folks on this list have read any RPM literature at all? Can only speak for myself: - "maximum RPM" is OK but old: http://www.rpm.org/max-rpm/ - "the fight" is only so helpful: http://freshrpms.net/docs/fight/ - the guru guide is OK but only saw it recently: http://www.gurulabs.com/goodies/guru+guides.php 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 ivazquez at ivazquez.net Wed Apr 27 22:05:48 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Apr 2005 18:05:48 -0400 Subject: NIS server tool In-Reply-To: <1114632432.426ff0f0f40d4@pah.cert.ucr.edu> References: <1114632432.426ff0f0f40d4@pah.cert.ucr.edu> Message-ID: <1114639548.5061.14.camel@ignacio.ignacio.lan> On Wed, 2005-04-27 at 13:07 -0700, glen at mail.cert.ucr.edu wrote: > Hi there, > > So I put together a little app for configuring an NIS server, and I was hoping > to get it into Fedora extras. You can check it out here by the way: > http://pah.cert.ucr.edu/~glen/system-config-nis.tar.bz2 > > In looking at the extras site it looks like I'll need someone to sponser me > before I can get my junk added to extras, and so I was hoping someone could > sponser me, or at least let me know what else I need to do at this point to get > my package accepted. http://www.fedoraproject.org/wiki/NewPackageProcess The first step would be to actually create a package, and not just have a tarball for 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 perbj at stanford.edu Wed Apr 27 22:25:46 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 27 Apr 2005 15:25:46 -0700 Subject: New Package Process In-Reply-To: <1114639161.6220.85.camel@ernie> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> <1114639161.6220.85.camel@ernie> Message-ID: <1114640747.4811.26.camel@localhost.localdomain> On Wed, 2005-04-27 at 17:59 -0400, Ed Hill wrote: > On Wed, 2005-04-27 at 15:58 -0400, Greg DeKoenigsberg wrote: > > How many of the folks on this list have read any RPM literature at all? > - "maximum RPM" is OK but old: > http://www.rpm.org/max-rpm/ The "CVS snapshot" version is much better, it has been updated significantly: http://www.rpm.org/max-rpm-snapshot/ This has often been my main guide for building packages and it's generally quite useful for understanding what is going on. (I sort of wish that this version were promoted to some more official status, the original version is so out of date in some ways.) /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From bugs.michael at gmx.net Wed Apr 27 22:45:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Apr 2005 00:45:28 +0200 Subject: New Package Process In-Reply-To: <1114639161.6220.85.camel@ernie> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> <1114639161.6220.85.camel@ernie> Message-ID: <20050428004528.0063b240.bugs.michael@gmx.net> On Wed, 27 Apr 2005 17:59:21 -0400, Ed Hill wrote: > - the guru guide is OK but only saw it recently: > http://www.gurulabs.com/goodies/guru+guides.php Did I skim over it too fast or does it really not explain dependencies and build requirements at all? Else it's useful for newbies. Maybe even a bit complex due to the long task-oriented second part. > - "maximum RPM" is OK but old: > http://www.rpm.org/max-rpm/ A somewhat enhanced and revised version: http://www.rpm.org/max-rpm-snapshot/ From ivazquez at ivazquez.net Wed Apr 27 22:52:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 27 Apr 2005 18:52:52 -0400 Subject: Review Request: inadyn In-Reply-To: References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> Message-ID: <1114642372.5061.18.camel@ignacio.ignacio.lan> On Wed, 2005-04-27 at 19:15 +0200, Jochen Schmitt wrote: > On Wed, 27 Apr 2005 11:15:16 -0400, you wrote: > > >That's what $! in bash is for. Just capture the PID via that and send it > >to a file. > > I have try it, and it seems, it didn't work. Hmm. I'm not quite sure why it wouldn't. Ah well, it's not as though running more than one copy of inadyn makes sense anyways. > I have wrote a initscript without capturing of the PID and have > checked in the CVS. Line 47 says "$ez_pid" when it should probably be "$ina_pid". Also, inadyn doesn't seem to be working for me. All I get, even under "verbose 5", is the following in my system log: Apr 27 18:47:13 ignacio INADYN[26652]: W:INADYN: DYNDNS Server response: HTTP/1. nohost ion: closet/plain; charset=ISO-8859-1 -- 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 Thu Apr 28 00:59:20 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 27 Apr 2005 20:59:20 -0400 Subject: New Package Process -- lets create a page of links for newbies In-Reply-To: <20050428004528.0063b240.bugs.michael@gmx.net> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> <1114639161.6220.85.camel@ernie> <20050428004528.0063b240.bugs.michael@gmx.net> Message-ID: <1114649961.6220.99.camel@ernie> On Thu, 2005-04-28 at 00:45 +0200, Michael Schwendt wrote: > > A somewhat enhanced and revised version: > http://www.rpm.org/max-rpm-snapshot/ Hey, that is an improvement over the old version! But like Per mentioned, unless you know that it exists you're not at all likely to find it. `But look you found the notice didn't you?' `Yes,' said Arthur, `yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".'" So how do I get Wiki write permission in order to create a collection of links for newbie packagers? 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 perbj at stanford.edu Thu Apr 28 01:33:16 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 27 Apr 2005 18:33:16 -0700 Subject: New Package Process -- lets create a page of links for newbies In-Reply-To: <1114649961.6220.99.camel@ernie> References: <20050426101829.75c1ab59.bugs.michael@gmx.net> <1114504096.7784.57.camel@ignacio.ignacio.lan> <20050426122902.22ebdbba.bugs.michael@gmx.net> <1114515650.7784.80.camel@ignacio.ignacio.lan> <20050426135322.754a1d2d.bugs.michael@gmx.net> <1114556738.7784.90.camel@ignacio.ignacio.lan> <426F00FD.2010505@redhat.com> <20050427120347.41cfd346.bugs.michael@gmx.net> <426F66D1.6070502@redhat.com> <20050427145350.GA20560@ryoko.camperquake.de> <20050427173019.6ef17a36.bugs.michael@gmx.net> <1114622252.24385.134.camel@mccallum.corsepiu.local> <1114630808.6220.65.camel@ernie> <1114639161.6220.85.camel@ernie> <20050428004528.0063b240.bugs.michael@gmx.net> <1114649961.6220.99.camel@ernie> Message-ID: <1114651996.4811.49.camel@localhost.localdomain> On Wed, 2005-04-27 at 20:59 -0400, Ed Hill wrote: > So how do I get Wiki write permission in order to create a collection of > links for newbie packagers? Just get yourself a Wiki account by clicking the UserPreferences link in the upper right corner of the page, and then someone in the EditGroup can add you so that you can edit and add pages. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From hula-kevin at iprone.com Thu Apr 28 04:14:05 2005 From: hula-kevin at iprone.com (Kevin Gray) Date: Thu, 28 Apr 2005 00:14:05 -0400 Subject: Request for Review: hula In-Reply-To: <200504152033.23317.hula-kevin@iprone.com> References: <200504152033.23317.hula-kevin@iprone.com> Message-ID: <4270630D.8060108@iprone.com> Just another request for review of hula. I didnt give a link to the actual package last time. It can be downloaded at http://files.iprone.com/. -- Kevin Gray hula [dash] kevin [at] iprone.com From adrian at lisas.de Thu Apr 28 06:11:24 2005 From: adrian at lisas.de (Adrian Reber) Date: Thu, 28 Apr 2005 08:11:24 +0200 Subject: sponsor and review request: rzip In-Reply-To: <20050426125117.GH11570@stingr.stingr.net> References: <20050424100720.GE11570@stingr.stingr.net> <20050424103448.GA25200@lisas.de> <20050424150322.GG11570@stingr.stingr.net> <20050425171212.GA552@lisas.de> <20050426125117.GH11570@stingr.stingr.net> Message-ID: <20050428061124.GA29085@lisas.de> On Tue, Apr 26, 2005 at 04:51:17PM +0400, Paul P Komkoff Jr wrote: > Replying to Adrian Reber: > > Looks good: > > > > def565356064834503d603ba1cf61d5e rzip-2.0-1.src.rpm > > > > Sources match upstream: > > > > 8a88b445afba919b122a3899d6d26b2a rzip-2.0.tar.gz > > > > Spec looks good. Rebuilds cleanly in mach. > > What's next? I am not really sure what the next step is. Maybe someone with a clue can tell you what the next steps are. Adrian -- Adrian Reber http://lisas.de/~adrian/ We didn't pay the Internet bill and it's been cut off. From skvidal at phy.duke.edu Thu Apr 28 06:20:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Apr 2005 02:20:38 -0400 Subject: extras status report Message-ID: <1114669238.20429.8.camel@cutter> Hey Everyone, I've been kinda silent for the past week b/c I've been busy and frustrated - I just wanted to give everyone a heads up as to what I've been doing and what the reason is I've not built the set of packages on the wiki build request pages. I've been working rather diligently but frustratingly on the build system automation parts. This is to make it so that no one has to manually run the builds but so that the package maintainers can request a build on their own. Right now it's doing a fairly good job but I've got a couple of bugs that are making it very very hard to use normally. I've posted the latest code to the steering committee list but I've not checked it into cvs yet. Until it's in cvs I'll post it at: http://linux.duke.edu/~skvidal/misc/buildsys/ There are some todos left to accomplish and as soon as I get around this one bug I'll hit them. Once this is all happy then we'll open up the 'make build' command to all the packagers so they can request builds of their packages w/o having to go through me. The only part I'll be involved in will be signing and pushing the packages but that part can really be handled by anyone with the signing keys. I know I'll be happy to no longer be the bottleneck in that process and so will everyone else. I just felt like I'd been kinda silent since encountering this problem and I wanted to fill everyone in. -sv From ville.skytta at iki.fi Thu Apr 28 06:36:48 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 28 Apr 2005 09:36:48 +0300 Subject: extras status report In-Reply-To: <1114669238.20429.8.camel@cutter> References: <1114669238.20429.8.camel@cutter> Message-ID: <1114670208.16489.108.camel@bobcat.mine.nu> On Thu, 2005-04-28 at 02:20 -0400, seth vidal wrote: > I've been kinda silent for the past week b/c I've been busy and > frustrated - I just wanted to give everyone a heads up as to what I've > been doing and what the reason is I've not built the set of packages on > the wiki build request pages. Thanks for the update and the hard work. However, before the "make build" stuff is available, would it be possible to build at least sylpheed-claws for both FC3 and devel? It's marked as a security update in Wiki. If you're willing to do more builds manually at this time, wxGTK for devel looks like the next important one in the queue to me. From ivazquez at ivazquez.net Thu Apr 28 06:46:40 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Apr 2005 02:46:40 -0400 Subject: sponsor and review request: rzip In-Reply-To: <20050428061124.GA29085@lisas.de> References: <20050424100720.GE11570@stingr.stingr.net> <20050424103448.GA25200@lisas.de> <20050424150322.GG11570@stingr.stingr.net> <20050425171212.GA552@lisas.de> <20050426125117.GH11570@stingr.stingr.net> <20050428061124.GA29085@lisas.de> Message-ID: <1114670800.5061.20.camel@ignacio.ignacio.lan> On Thu, 2005-04-28 at 08:11 +0200, Adrian Reber wrote: > On Tue, Apr 26, 2005 at 04:51:17PM +0400, Paul P Komkoff Jr wrote: > > Replying to Adrian Reber: > > > Looks good: > > > > > > def565356064834503d603ba1cf61d5e rzip-2.0-1.src.rpm > > > > > > Sources match upstream: > > > > > > 8a88b445afba919b122a3899d6d26b2a rzip-2.0.tar.gz > > > > > > Spec looks good. Rebuilds cleanly in mach. > > > > What's next? > > I am not really sure what the next step is. Maybe someone with a clue > can tell you what the next steps are. The next step would be to import it into CVS. -- 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 mpeters at mac.com Thu Apr 28 06:49:21 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 27 Apr 2005 23:49:21 -0700 Subject: Request for Review: gstreamer-plugins-libvisual Message-ID: <1114670961.11644.62.camel@fc4t2.mpeters.local> This package consists of a gstreamer plugin that allows some applications to access the libvisual library through gstreamer. One such application (and the only one I have tried) is totem. The totem in fedora core 3 has visualizer support turned off (unless it has been updated) and the gstreamer-plugins in core 3 is too old for the current version of libvisual in extras, so this package should only target rawhide/core 4 spec: http://mpeters.us/fc_extras/gstreamer-plugins-libvisual.spec src.rpm: http://mpeters.us/fc_extras/gstreamer-plugins-libvisual-0.8.8-0.2.src.rpm This package depends upon libvisual-plugins only tested by me on x86 -=- There are a few other gstreamer plugins that potentially could be built for extras. If that should happen, it would (imho) be better to use a single spec file to build them, simply because there aren't *that* many that don't have patent constraints that are not already in core, and it makes more sense (to me) to have a single spec file per src tarball. Would it be better to call the src rpm gstreamer-plugins-extras and just make libvisual a subpackage to facilitate that should other plugins be desired in extras? From mpeters at mac.com Thu Apr 28 06:49:19 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 27 Apr 2005 23:49:19 -0700 Subject: Request for Review: libvisual-plugins Message-ID: <1114670959.11644.61.camel@fc4t2.mpeters.local> libvisual-plugins is a package that provides visualizers for use with libvisual. Many applications, such as xmms and gstreamer (and AmoroK from what I hear) can then use the visualizers if they are linked against libvisual (or have the appropriate plugin built) spec file: http://mpeters.us/fc_extras/libvisual-plugins.spec src.rpm: http://mpeters.us/fc_extras/libvisual-plugins-0.2.0-0.2.src.rpm One plugin is disabled because of a gcc4 compile issue. Several other plugins are disabled because they are broken, and if selected in totem as the visualizer, cause totem to fail in a bad way (says it can not play the song for an unknown reason) This package should build in either fc3 or rawhide, I have only tested this spec file in rawhide, but it is a cleaned up version of what did work (for me) in Core3. Only tested on x86. I have not yet verified that all the BuildRequires are in fact specified, that will happen this weekend. From bugs.michael at gmx.net Thu Apr 28 09:08:26 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Apr 2005 11:08:26 +0200 Subject: sponsor and review request: rzip In-Reply-To: <1114670800.5061.20.camel@ignacio.ignacio.lan> References: <20050424100720.GE11570@stingr.stingr.net> <20050424103448.GA25200@lisas.de> <20050424150322.GG11570@stingr.stingr.net> <20050425171212.GA552@lisas.de> <20050426125117.GH11570@stingr.stingr.net> <20050428061124.GA29085@lisas.de> <1114670800.5061.20.camel@ignacio.ignacio.lan> Message-ID: <20050428110826.58254d05.bugs.michael@gmx.net> On Thu, 28 Apr 2005 02:46:40 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-04-28 at 08:11 +0200, Adrian Reber wrote: > > On Tue, Apr 26, 2005 at 04:51:17PM +0400, Paul P Komkoff Jr wrote: > > > Replying to Adrian Reber: > > > > Looks good: > > > > > > > > def565356064834503d603ba1cf61d5e rzip-2.0-1.src.rpm > > > > > > > > Sources match upstream: > > > > > > > > 8a88b445afba919b122a3899d6d26b2a rzip-2.0.tar.gz > > > > > > > > Spec looks good. Rebuilds cleanly in mach. > > > > > > What's next? > > > > I am not really sure what the next step is. Maybe someone with a clue > > can tell you what the next steps are. > > The next step would be to import it into CVS. Maybe, maybe not. The next step depends on how we work with _new_ contributors, who don't have CVS access yet and who have not appeared before [e.g. at fedora.us]. If the sponsors at Red Hat sponsor every contributor, who signs up for a CVS account, there would be no need for Adrian to import the package already now. He would be done [with his review] and could wait till Paul gets CVS access. Else Adrian would pick up the old idea of acting as a proxy to CVS for a new contributor for some time until he decides to sponsor the person's CVS account. In that case he would import the package now and accept patches from Paul, too. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1258_FC4 loadavg: 1.06 0.93 0.44 From gauret at free.fr Thu Apr 28 09:46:28 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 28 Apr 2005 11:46:28 +0200 Subject: Request for Review: libvisual-plugins References: <1114670959.11644.61.camel@fc4t2.mpeters.local> Message-ID: Works for me with Amarok on FC3 About the spec file : * Files section : you could just delete the .la files in %install, with the command "find %buildroot%_libdir -type f -name "*.la" -exec rm -f {} ';'" and your files section would boil down to: %{_libdir}/libvisual %{_datadir}/libvisual %{_datadir}/libvisual-plugins (just an advice, you're the one maintaining in the end...) * BuildRequirements You should add xorg-x11, because a makefile in the G-Force plugin dir uses the command "mkdirhier" (build fails in mach without it, succeeds with it) Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From mpeters at mac.com Thu Apr 28 10:32:57 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 28 Apr 2005 03:32:57 -0700 Subject: Request for Review: libvisual-plugins In-Reply-To: References: <1114670959.11644.61.camel@fc4t2.mpeters.local> Message-ID: <1114684377.11644.80.camel@fc4t2.mpeters.local> On Thu, 2005-04-28 at 11:46 +0200, Aurelien Bompard wrote: > Works for me with Amarok on FC3 > > About the spec file : > * Files section : you could just delete the .la files in %install, with the > command "find %buildroot%_libdir -type f -name "*.la" -exec rm -f {} ';'" > and your files section would boil down to: > %{_libdir}/libvisual > %{_datadir}/libvisual > %{_datadir}/libvisual-plugins > (just an advice, you're the one maintaining in the end...) done > > * BuildRequirements > You should add xorg-x11, because a makefile in the G-Force plugin dir uses > the command "mkdirhier" (build fails in mach without it, succeeds with it) done - though I would think requiring xorg-x11-devel would have pulled that in. Bug in xorg spec file? new package/spec file: http://mpeters.us/fc_extras/libvisual-plugins.spec http://mpeters.us/fc_extras/libvisual-plugins-0.2.0-0.3.src.rpm From ivazquez at ivazquez.net Thu Apr 28 11:12:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Apr 2005 07:12:39 -0400 Subject: Request for Review: libvisual-plugins In-Reply-To: <1114684377.11644.80.camel@fc4t2.mpeters.local> References: <1114670959.11644.61.camel@fc4t2.mpeters.local> <1114684377.11644.80.camel@fc4t2.mpeters.local> Message-ID: <1114686759.5061.22.camel@ignacio.ignacio.lan> On Thu, 2005-04-28 at 03:32 -0700, Michael A. Peters wrote: > On Thu, 2005-04-28 at 11:46 +0200, Aurelien Bompard wrote: > > * BuildRequirements > > You should add xorg-x11, because a makefile in the G-Force plugin dir uses > > the command "mkdirhier" (build fails in mach without it, succeeds with it) > > done - though I would think requiring xorg-x11-devel would have pulled > that in. Bug in xorg spec file? Not all -devel packages need the primary in order to just build other apps. -- 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 jwboyer at jdub.homelinux.org Thu Apr 28 12:52:55 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 28 Apr 2005 07:52:55 -0500 Subject: extras status report In-Reply-To: <1114669238.20429.8.camel@cutter> References: <1114669238.20429.8.camel@cutter> Message-ID: <20050428125255.GA12998@yoda.jdub.homelinux.org> On Thu, Apr 28, 2005 at 02:20:38AM -0400, seth vidal wrote: > > I just felt like I'd been kinda silent since encountering this problem > and I wanted to fill everyone in. Thanks for the update. I had been wondering why packages weren't getting built. josh From rc040203 at freenet.de Thu Apr 28 12:52:40 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 28 Apr 2005 14:52:40 +0200 Subject: Request for Review: libvisual-plugins In-Reply-To: <1114684377.11644.80.camel@fc4t2.mpeters.local> References: <1114670959.11644.61.camel@fc4t2.mpeters.local> <1114684377.11644.80.camel@fc4t2.mpeters.local> Message-ID: <1114692761.24385.213.camel@mccallum.corsepiu.local> On Thu, 2005-04-28 at 03:32 -0700, Michael A. Peters wrote: > On Thu, 2005-04-28 at 11:46 +0200, Aurelien Bompard wrote: > > Works for me with Amarok on FC3 > > > > About the spec file : > > * Files section : you could just delete the .la files in %install, with the > > command "find %buildroot%_libdir -type f -name "*.la" -exec rm -f {} ';'" > > and your files section would boil down to: > > %{_libdir}/libvisual > > %{_datadir}/libvisual > > %{_datadir}/libvisual-plugins > > (just an advice, you're the one maintaining in the end...) > > done > > > > > * BuildRequirements > > You should add xorg-x11, because a makefile in the G-Force plugin dir uses > > the command "mkdirhier" (build fails in mach without it, succeeds with it) > > done Well, this actually is an underdeveloped Makefile.am. Better patch the Makefile.am and Makefile.in to use $(mkinstalldirs) instead of mkdirhier. If there isn't any other dependency on xorg-x11 you should be able to avoid xorg-x11 entirely. > - though I would think requiring xorg-x11-devel would have pulled > that in. Bug in xorg spec file? Depends on what you mean. xorg-x11-devel doesn't have to depend on xorg-x11, because the corresponding libs are part of xorg-x11-libs. Having mkdirhier in xorg-x11 is arguable, but isn't actually wrong. mkdirhier is X11's workaround to "mkdir -p" not being available on many OSes. Historically it had been used outside of X11-development, which might explain, why it is in xorg-x11. Nowadays, mkdirhier more or less is an anachronism, only being used in Imakefiles. Automake configurations should either use automake's own mkinstalldirs, or (automake >= 1.9) should use $(mkdir_p). Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: libvisual-plugins.diff Type: text/x-patch Size: 1372 bytes Desc: not available URL: From jspaleta at gmail.com Thu Apr 28 14:20:46 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Apr 2005 10:20:46 -0400 Subject: New Package Process Message-ID: <604aa79105042807205fbd3555@mail.gmail.com> Greg DeKoenigsberg wrote: > 2. A policy of "build the world". Every package in the build system, we > build. If it passes, it goes into the "untested" bucket. This bucket > is also a repo, for those who dare. In Core that's called rawhide. Are you suggesting a rawhide like repo for Extras for every Core release? Just after fc4 release, you would have a 'build the world' extras repo for fc3 and fc4 and one tracking the deps in core development. I'm not sure that's such a great idea, considering the rolling release nature of Extras. Rawhide as a tool works for Core because rawhide is the staging area to work on integration issues before a release date AND just as importantly has freeze out points that can be used to be used to yank horribly broken packages out before a release of Core is frozen out. I'd be much more comfortable with a 'build the world' situation for Extras, if Extras had scheduled releases that were frozen out and associated timetables which could be used to determination points for culling packages in the 'build the world' repo which are still too crappy to enter the frozen Extras 'release'. With schedules and releases of Extras, so we can do things like an FedoraExtras blocker bug summary to focus and organize manpower on the 'important' issues before a designated 'release' of Extras. I think if you are going to stick with the rolling release you have to frontload some of the QA as a tradeoff to the rolling nature of the tree. > 3. A mechanism for "final review" that marks the difference between "a > package that builds" and "a package the builds and is any good". And > let's think creatively about this final review: does it need to be a > single person who says "this is ok, I bless it"? Or could it *also* be a > threshhold? For example: we could say that any package that is installed > 100 times from the untested repo, without anyone voting against it, > is automatically promoted to the "tested" bucket. This would provide two > paths: one path for packages that people are watching over, and a parallel > path for packages that people aren't watching over, but are still using. i don't think your automatic threshold idea is technically feasible. How would you determine download or mirroring from sucessful installing? How do you determine successful installing from usefully working. You aren't going to go so far as to actually require some sort of phone-home software from the client computer are you.. because that would be very silly. Technical questions aside, would this scheme work for Core rawhide? If Core followed a similar model.. and rawhide was the "build the world" repo, would this automatic threshold work? I highly doubt it. If you want a 'build-the-world' playground for package maintainers and competent package testers, structure the development model for Extras accordingly to strongly delineate the release tree from the build-playground. Everyone who is happy with the idea of the build-the-world tree with the rolling release model, is going on the list of people i'm going to throw users at as they stumble onto the build-the-world tree and get burned. Be prepared to spend a lot of time in fedora-list and the forums. I am fully confident in the ability of rank-and-file fedora packagers consumers to be easily misled into using the build-the-world tree for Extras if it becomes available. -jef"calling the new build-the-world tree "happy fun ball" might not even help http://www.happyfunball.com/hfb.html "spaleta From ivazquez at ivazquez.net Thu Apr 28 14:36:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Apr 2005 10:36:00 -0400 Subject: New Package Process In-Reply-To: <604aa79105042807205fbd3555@mail.gmail.com> References: <604aa79105042807205fbd3555@mail.gmail.com> Message-ID: <1114698961.5061.25.camel@ignacio.ignacio.lan> On Thu, 2005-04-28 at 10:20 -0400, Jeff Spaleta wrote: > Greg DeKoenigsberg wrote: > > 2. A policy of "build the world". Every package in the build system, we > > build. If it passes, it goes into the "untested" bucket. This bucket > > is also a repo, for those who dare. > > In Core that's called rawhide. No, it's called the fedora-extras-testing repo, which already exists. -- 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 Apr 28 14:38:55 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 28 Apr 2005 16:38:55 +0200 Subject: Review Request: inadyn In-Reply-To: <1114642372.5061.18.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> Message-ID: On Wed, 27 Apr 2005 18:52:52 -0400, you wrote: >Line 47 says "$ez_pid" when it should probably be "$ina_pid". Thank you, I have fixed is and checed into the CVS. >Apr 27 18:47:13 ignacio INADYN[26652]: W:INADYN: DYNDNS Server response: >HTTP/1. nohost ion: closet/plain; charset=ISO-8859-1 You have to enter your DynDSN username, password and the registered hostname to /etc/inadyn.conf. Perhaps, You have to enter yourfull quallified hostname in the config file, becouse DynDNS offers hostnames in defferent domains. You message look like, that you have enter only a short hostname without a domain part. Best Regards: Jochen Schmitt From ivazquez at ivazquez.net Thu Apr 28 14:46:33 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Apr 2005 10:46:33 -0400 Subject: Review Request: inadyn In-Reply-To: References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> Message-ID: <1114699593.5061.27.camel@ignacio.ignacio.lan> On Thu, 2005-04-28 at 16:38 +0200, Jochen Schmitt wrote: > On Wed, 27 Apr 2005 18:52:52 -0400, you wrote: > >Apr 27 18:47:13 ignacio INADYN[26652]: W:INADYN: DYNDNS Server response: > >HTTP/1. nohost ion: closet/plain; charset=ISO-8859-1 > > You have to enter your DynDSN username, password and the > registered hostname to /etc/inadyn.conf. > > Perhaps, You have to enter yourfull quallified hostname in the > config file, becouse DynDNS offers hostnames in defferent > domains. You message look like, that you have enter only a short > hostname without a domain part. No, I put in a fully-qualified name. Does the hostname have to be registered via the website at least once for it to work? -- 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 Thu Apr 28 14:54:17 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Apr 2005 10:54:17 -0400 Subject: New Package Process In-Reply-To: <1114698961.5061.25.camel@ignacio.ignacio.lan> References: <604aa79105042807205fbd3555@mail.gmail.com> <1114698961.5061.25.camel@ignacio.ignacio.lan> Message-ID: <604aa7910504280754389c5d8a@mail.gmail.com> On 4/28/05, Ignacio Vazquez-Abrams wrote: > > No, it's called the fedora-extras-testing repo, which already exists. Is extras-testing going to be used for building the world, where every package in cvs is built and available? or for targetted package testing like we see in updates-testing for Core? I would caution you to not reuse the the phrase *-testing at this point for a build-the-world shadow tree of Extras cvs. Call it something else, because its going to cause unnecessary confusion in the userbase if updates-testing and extras-testing fill different functional roles. -jef"never use volume-manager when you want volume-control or vice-versa"spaleta From mpeters at mac.com Thu Apr 28 15:01:05 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 28 Apr 2005 08:01:05 -0700 Subject: Request for Review: libvisual-plugins In-Reply-To: <1114692761.24385.213.camel@mccallum.corsepiu.local> References: <1114670959.11644.61.camel@fc4t2.mpeters.local> <1114684377.11644.80.camel@fc4t2.mpeters.local> <1114692761.24385.213.camel@mccallum.corsepiu.local> Message-ID: <1114700465.11644.84.camel@fc4t2.mpeters.local> On Thu, 2005-04-28 at 14:52 +0200, Ralf Corsepius wrote: > > Better patch the Makefile.am and Makefile.in to use $(mkinstalldirs) > instead of mkdirhier. > > If there isn't any other dependency on xorg-x11 you should be able to > avoid xorg-x11 entirely. *snip* > > mkdirhier is X11's workaround to "mkdir -p" not being available on many > OSes. Historically it had been used outside of X11-development, which > might explain, why it is in xorg-x11. Nowadays, mkdirhier more or less > is an anachronism, only being used in Imakefiles. > Automake configurations should either use automake's own mkinstalldirs, > or (automake >= 1.9) should use $(mkdir_p). Thank you for the info! I'll patch it to do it the "right" way. From bugs.michael at gmx.net Thu Apr 28 16:39:21 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 28 Apr 2005 18:39:21 +0200 Subject: New Package Process In-Reply-To: <604aa7910504280754389c5d8a@mail.gmail.com> References: <604aa79105042807205fbd3555@mail.gmail.com> <1114698961.5061.25.camel@ignacio.ignacio.lan> <604aa7910504280754389c5d8a@mail.gmail.com> Message-ID: <20050428183921.74b13732.bugs.michael@gmx.net> On Thu, 28 Apr 2005 10:54:17 -0400, Jeff Spaleta wrote: > On 4/28/05, Ignacio Vazquez-Abrams wrote: > > > > No, it's called the fedora-extras-testing repo, which already exists. > > Is extras-testing going to be used for building the world, where every > package in cvs is built and available? or for targetted package > testing like we see in updates-testing for Core? The latter. From mike at flyn.org Thu Apr 28 16:55:15 2005 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 28 Apr 2005 11:55:15 -0500 Subject: Request for Review: pam_mount Message-ID: <20050428165515.GA19592@imp.flyn.org> In response to Bugzilla bug #156239, FC4 rebuild failed, I would like to request volunteers for a review of a new pam_mount package. Pam_mount is aimed at environments with SMB (Samba or Windows NT) or NCP (Netware or Mars-NWE) servers that Unix users wish to access transparently. It uses a user's system password to mount remote volumes when the user logs in. src rpm: http://www.flyn.org/projects/pam_mount/pam_mount-0.9.23-0.fdr.1.src.rpm MD5 message digest: 9f44d93463f027d7c3ae5a5a3c824eb3 pam_mount-0.9.23-0.fdr.1.src.rpm Older versions of pam_mount have been accepted into Extras. However, the last Extras version will not compile on Fedora Core 4. This new version should compile for Fedora Core 4 and also includes several other bug fixes. -- Mike :wq -------------- 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 Thu Apr 28 18:18:51 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 28 Apr 2005 20:18:51 +0200 Subject: Review Request: inadyn In-Reply-To: <1114699593.5061.27.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> Message-ID: <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> On Thu, 28 Apr 2005 10:46:33 -0400, you wrote: >No, I put in a fully-qualified name. Does the hostname have to be >registered via the website at least once for it to work? Yes of course. After you have create a dynDNS account, you have to register the hostname, you want to use, on the DynDNS website. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Thu Apr 28 18:23:24 2005 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 28 Apr 2005 20:23:24 +0200 Subject: Request for Review: monotone In-Reply-To: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> References: <1113423009.4199.68.camel@lt16586.campus.dmacc.edu> Message-ID: On Wed, 13 Apr 2005 15:10:09 -0500, you wrote: >(probably something related to gcc4). If anyone can get monotone >compiling on FC4 I'd appreciate it if you'd let me know. If you google for 'monotone gcc4' you may find a CVS entry, which explain a patch to get monotone to compiled with gcc 4.0. Unfortunately, the current CVS tree I checked out today failed to build on my computer. Best Regards: Jochen Schmitt From j.w.r.degoede at hhs.nl Thu Apr 28 18:42:41 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 28 Apr 2005 20:42:41 +0200 Subject: Imported to CVS, review requested: Glide3 Message-ID: <42712EA1.2050401@hhs.nl> Hi, I've been busy creating a new Glide3 package for FE for FC4, since Glide3 will be dropped from core and I have imported my work into CVS, please review. This package is based on the Glide3 core CVS tree for FC-2, this because some earlier fixes of mine were committed to Fedora-Core CVS FC-2 instead of FC-3/devel by accident. FC2 contained a release of 34 and FC-3 and devel of 33. Although AFAIK the FC-2 34 release in CVS was nevewr build (because comitted to the wrong branch) I've made the new release tag 35 just to be sure. The 2 main changes to this package form FC-2 CVS are a patch which is nescesarry to compile this with gcc4 and some specfile cleanups to better match most FE specfiles. Regards, Hans From j.w.r.degoede at hhs.nl Thu Apr 28 19:21:23 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 28 Apr 2005 21:21:23 +0200 Subject: sponsors still needed for new packages, extras not advertised on fedorawebsite? Message-ID: <427137B3.9080009@hhs.nl> Hi, AFAIK sponsorship is no longer needed to get CVS access, instead one should go through the new webinterface, right? (I already have CVS access, just checking) What about new packages, I see a lot of review requests for new packages on this list without first seeing a sponsor request. So are sponsors still needed for new packages? Or is the idea that if someone reviews it and approves it that he then also automaticly sponsers it, in that case shouldn't: http://fedoraproject.org/wiki/NewPackageProcess be updated? Also I miss a link to: https://admin.fedora.redhat.com/accounts/ and: http://fedoraproject.org/wiki/NewPackageProcess from: http://cvs.fedora.redhat.com/extras.shtml A link there would be helpfull for people who want to contribute. I also see now links about (contributing to) Extras, or to cvs.fedora.redhat.com from fedora.redhat.com. Are we trying to keep CVS and extras a secret? Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 28 19:30:29 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 28 Apr 2005 21:30:29 +0200 Subject: Regarding noarch packages Message-ID: <20050428213029.20ce9e76@python2> Hi, While trying to rebuild a package on x86_64 development that requires scons to build, I noticed that scons, which is a noarch packages, is only present in the i386 directory, not the x86_64 one. So I guess this is possibly just something seth missed if it's "manually done" ;-) But otherwise, we may need some way of being sure that all noarch packages appear for all archs, or maybe some way of letting the tree populating script know on which arches a noarch package is relevant (for instance, I have some firmware packages that are needed only for x86 hardware, so although they are noarch, they aren't relevant on other platforms). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.51 0.46 0.52 From skvidal at phy.duke.edu Thu Apr 28 19:38:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Apr 2005 15:38:59 -0400 Subject: Regarding noarch packages In-Reply-To: <20050428213029.20ce9e76@python2> References: <20050428213029.20ce9e76@python2> Message-ID: <1114717139.18815.1.camel@opus.phy.duke.edu> On Thu, 2005-04-28 at 21:30 +0200, Matthias Saou wrote: > Hi, > > While trying to rebuild a package on x86_64 development that requires > scons to build, I noticed that scons, which is a noarch packages, is only > present in the i386 directory, not the x86_64 one. > > So I guess this is possibly just something seth missed if it's "manually > done" ;-) But otherwise, we may need some way of being sure that all > noarch packages appear for all archs, or maybe some way of letting the > tree populating script know on which arches a noarch package is relevant > (for instance, I have some firmware packages that are needed only for x86 > hardware, so although they are noarch, they aren't relevant on other > platforms). > The buildsystem code I posted last night already handles SOME of that. Noarch are only built once and moved into all of the arch directories. You're right scons was probably just a screw up on my part. -sv From j.w.r.degoede at hhs.nl Thu Apr 28 19:43:05 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 28 Apr 2005 21:43:05 +0200 Subject: Sponsor request: descent (d1x) Message-ID: <42713CC9.9070703@hhs.nl> Hi, Anyone agrees that descent (the 3d shoot em up) is great and belongs in extras (iow wants to sponsor me)? There has been a free (opensource) release of the descent engine and this has been ported to linux and enhanced under the name of d1x: http://d1x.warpcore.org I know it needs shareware datafiles, this has been looked at by legal as requested by me and according to: http://fedoraproject.org/wiki/PackagingGuidelines shareware datafiles are ok as long as they are freely redistributable. Atleast I assume the text about shareware was added because of my request to look into this, a reply to my original mail pointing at this would have been nice. I've build a specifle for this sometime ago and would like to import this into CVS and then get it reviewed. But since its a new package I need a sponsor before import to CVS according to: http://fedoraproject.org/wiki/NewPackageProcess Thanks & Regards, Hans From tcallawa at redhat.com Thu Apr 28 20:02:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 28 Apr 2005 15:02:25 -0500 Subject: Sponsor request: descent (d1x) In-Reply-To: <42713CC9.9070703@hhs.nl> References: <42713CC9.9070703@hhs.nl> Message-ID: <1114718545.3333.5.camel@localhost.localdomain> On Thu, 2005-04-28 at 21:43 +0200, Hans de Goede wrote: > Hi, > > Anyone agrees that descent (the 3d shoot em up) is great and belongs in > extras (iow wants to sponsor me)? > > There has been a free (opensource) release of the descent engine and > this has been ported to linux and enhanced under the name of d1x: > http://d1x.warpcore.org > > I know it needs shareware datafiles, this has been looked at by legal as > requested by me and according to: > http://fedoraproject.org/wiki/PackagingGuidelines > shareware datafiles are ok as long as they are freely redistributable. > Atleast I assume the text about shareware was added because of my > request to look into this, a reply to my original mail pointing at this > would have been nice. Yes, this was a result of that thread, sorry for not replying to your original mail. It was an oversight on my part. Post a link to the SRPM, and I'll review it. Also, you'll need to make sure that the distribution permissions for the shareware datafiles are included within the SRPM in writing. Thanks, ~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 mricon at gmail.com Thu Apr 28 20:10:01 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 28 Apr 2005 16:10:01 -0400 Subject: Cosponsor needed: pylint In-Reply-To: References: Message-ID: On 4/26/05, Konstantin Ryabitsev wrote: > Hello, all: > > I've reworked pylint and python-logilab-common packages significantly, > so they should be Much Better(tm). See > http://phy.duke.edu/~icon/misc/fedora-extras/. > > Would anyone like to co-sponsor me to add them to extras? Give me a > nod and I'll import them. Still waiting for someone to co-sponsor me. That's the procedure, right? Someone just say "aye." Regards, -- Konstantin Ryabitsev Zlotniks, INC From mricon at gmail.com Thu Apr 28 21:31:03 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 28 Apr 2005 17:31:03 -0400 Subject: Help needed: SCIM Message-ID: Hello: I need help with packaging SCIM, so if anyone wants to help, please let me know. What is SCIM: SCIM project already ships a wide range of input methods (some may need other libraries), covering more than 30 languages, most noticably including (Simplified/Tranditional) Chinese, Japanese, Korean and a bunch of European Languages. What's more, Composing/Dead key support is one of the built-in features. In addition to that, several projects are established to design IMEngines for SCIM and others supply their own SCIM plugins. http://www.scim-im.org/ Some people find it the most-featured Input Method for Chinese. I use it because it seems to be the only one that comes with the Wubi input method, and because I seem to have fewer problems with it than with IIIMF and the im-switcher applet. So far I have packaged: scim: the underlying infrastructure scim-pinyin: Smart Pinyin input method for Chinese scim-tables: a collection of several dozen input method tables for CJK see these here: http://phy.duke.edu/~icon/misc/fedora-extras/ This seems to be sufficient for most uses under gnome, though there are several other projects, including scim-hangul, skimm for KDE, and several implementations written to interact with other Input Method systems, such as UIM and M17N. Since IM systems isn't something I'm familiar with, I can't say whether it's something that should be packaged for extras, of if it's best left out. I know UIM is already in extras, but that's as much as I know about it. I'll package scim-hangul, and try my hand at skimm, but since I don't use KDE, that's probably not the best. Is anyone here writing much in CJK? Under KDE? Cheers, -- Konstantin Ryabitsev Zlotniks, INC From petersen at redhat.com Thu Apr 28 21:52:20 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Apr 2005 06:52:20 +0900 Subject: Help needed: SCIM In-Reply-To: References: Message-ID: <42715B14.5090702@redhat.com> Konstantin Ryabitsev wrote: > I need help with packaging SCIM, so if anyone wants to help, please > let me know. I recommend you talk to Ryo Dairiki, who has been packaging scim and skim upstream for Fedora and is planning to contribute them to Fedora Extras soon. :-) Cheers, Jens From tcallawa at redhat.com Thu Apr 28 23:04:27 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 28 Apr 2005 18:04:27 -0500 Subject: Request for Review: bmp-flac In-Reply-To: <20050419222344.3da5dd23.bugs.michael@gmx.net> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> <20050419212110.698d558b@nausicaa.camperquake.de> <20050419222344.3da5dd23.bugs.michael@gmx.net> Message-ID: <1114729468.3333.12.camel@localhost.localdomain> On Tue, 2005-04-19 at 22:23 +0200, Michael Schwendt wrote: > * Doesn't work for me. Steps to reproduce: > > 1. take an arbitrary .WAV file > 2. encode it with "flac filename.wav" > 3. load "filename.flac" into BMP > > Result: Invalid FLAC File: "file:///..." > > The reason is that the "filename" argument passed to plugin code > is prefixed with "file://", which you need to strip off in the > plugin callback functions. I've ported xmms-fc to BMP a week > ago to have more code for testing BMP and ran into the same > issue. Patch attached to resolve this blocker. Confirmed that it works (with Dave Grohl's 1993 pre Foo Fighters demo tape!). ~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! -------------- next part -------------- A non-text attachment was scrubbed... Name: bmp-flac-2-filestrip.patch Type: text/x-patch Size: 1939 bytes Desc: not available URL: From ivazquez at ivazquez.net Thu Apr 28 23:08:47 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Apr 2005 19:08:47 -0400 Subject: Review Request: inadyn In-Reply-To: <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> Message-ID: <1114729727.5061.34.camel@ignacio.ignacio.lan> On Thu, 2005-04-28 at 20:18 +0200, Jochen Schmitt wrote: > On Thu, 28 Apr 2005 10:46:33 -0400, you wrote: > > >No, I put in a fully-qualified name. Does the hostname have to be > >registered via the website at least once for it to work? > > Yes of course. > > After you have create a dynDNS account, you have to register the > hostname, you want to use, on the DynDNS website. Nope, still didn't work. I went to DynDNS's website, created the host entry as 127.0.0.1, and still got the same output from inadyn. -- 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 Apr 28 23:17:52 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 28 Apr 2005 16:17:52 -0700 Subject: Review Request: inadyn In-Reply-To: <1114729727.5061.34.camel@ignacio.ignacio.lan> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> Message-ID: <1114730272.4620.33.camel@localhost.localdomain> On Thu, 2005-04-28 at 19:08 -0400, Ignacio Vazquez-Abrams wrote: > > After you have create a dynDNS account, you have to register the > > hostname, you want to use, on the DynDNS website. > > Nope, still didn't work. I went to DynDNS's website, created the host > entry as 127.0.0.1, and still got the same output from inadyn. Eh... Can you explain what you are doing a bit more, actually? What you register with DynDNS is the DNS name you want; you then talk to the DynDNS server (using e.g. inadyn) every time you get assigned a new IP address and ask it to update the DNS mapping. If you go to the DynDNS website and try to map .dyndns.org to 127.0.0.1, that really won't work to well, at least I can't see how it can possibly be useful... /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From ivazquez at ivazquez.net Thu Apr 28 23:34:08 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 28 Apr 2005 19:34:08 -0400 Subject: Review Request: inadyn In-Reply-To: <1114730272.4620.33.camel@localhost.localdomain> References: <1114464378.7784.49.camel@ignacio.ignacio.lan> <0ML21M-1DQRXN2I2w-0004zr@mrelayeu.kundenserver.de> <0MKxQS-1DQo9k40Yz-00056x@mrelayeu.kundenserver.de> <1114614916.5061.12.camel@ignacio.ignacio.lan> <1114642372.5061.18.camel@ignacio.ignacio.lan> <1114699593.5061.27.camel@ignacio.ignacio.lan> <0ML2Dk-1DRDb81Qoz-0002e8@mrelayeu.kundenserver.de> <1114729727.5061.34.camel@ignacio.ignacio.lan> <1114730272.4620.33.camel@localhost.localdomain> Message-ID: <1114731248.5061.40.camel@ignacio.ignacio.lan> On Thu, 2005-04-28 at 16:17 -0700, Per Bjornsson wrote: > On Thu, 2005-04-28 at 19:08 -0400, Ignacio Vazquez-Abrams wrote: > > > After you have create a dynDNS account, you have to register the > > > hostname, you want to use, on the DynDNS website. > > > > Nope, still didn't work. I went to DynDNS's website, created the host > > entry as 127.0.0.1, and still got the same output from inadyn. > > Eh... Can you explain what you are doing a bit more, actually? What you > register with DynDNS is the DNS name you want; you then talk to the > DynDNS server (using e.g. inadyn) every time you get assigned a new IP > address and ask it to update the DNS mapping. Yes, this I understand. I'm no stranger to dynamic DNS services. > If you go to the DynDNS website and try to map .dyndns.org to > 127.0.0.1, that really won't work to well, at least I can't see how it > can possibly be useful... It does provide a convenient baseline from which a DynDNS client's success can be measured. If it's no longer 127.0.0.1 after the update then it's succeeded. What really bugs me about this problem is that I don't get any useful diagnostics from the program whatsoever, even at maximum verbosity. -- 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 Fri Apr 29 03:09:38 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 28 Apr 2005 23:09:38 -0400 Subject: Help needed: SCIM In-Reply-To: <42715B14.5090702@redhat.com> References: <42715B14.5090702@redhat.com> Message-ID: On 4/28/05, Jens Petersen wrote: > Konstantin Ryabitsev wrote: > > I need help with packaging SCIM, so if anyone wants to help, please > > let me know. > > I recommend you talk to Ryo Dairiki, who has been packaging > scim and skim upstream for Fedora and is planning to > contribute them to Fedora Extras soon. :-) Ah! That makes me very happy. SCIM is an excellent project and I would be glad to offer any help in packaging it, if needed. Regards, -- Konstantin Ryabitsev Zlotniks, INC From j.w.r.degoede at hhs.nl Fri Apr 29 06:29:51 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 08:29:51 +0200 Subject: Sponsor request: descent (d1x) In-Reply-To: <1114718545.3333.5.camel@localhost.localdomain> References: <42713CC9.9070703@hhs.nl> <1114718545.3333.5.camel@localhost.localdomain> Message-ID: <4271D45F.8090608@hhs.nl> Tom 'spot' Callaway wrote: > On Thu, 2005-04-28 at 21:43 +0200, Hans de Goede wrote: > >>Hi, >> >>Anyone agrees that descent (the 3d shoot em up) is great and belongs in >>extras (iow wants to sponsor me)? >> >>There has been a free (opensource) release of the descent engine and >>this has been ported to linux and enhanced under the name of d1x: >>http://d1x.warpcore.org >> >>I know it needs shareware datafiles, this has been looked at by legal as >>requested by me and according to: >>http://fedoraproject.org/wiki/PackagingGuidelines >>shareware datafiles are ok as long as they are freely redistributable. >>Atleast I assume the text about shareware was added because of my >>request to look into this, a reply to my original mail pointing at this >>would have been nice. > > > Yes, this was a result of that thread, sorry for not replying to your > original mail. It was an oversight on my part. > > Post a link to the SRPM, and I'll review it. Also, you'll need to make > sure that the distribution permissions for the shareware datafiles are > included within the SRPM in writing. > I'm still confused about the new package process according to the wiki the steps are: 1) get a sponsor -> done 2) import to CVS 3) request review So why do you request a link, shouldn't I import it into CVS? Regards, Hans From j.w.r.degoede at hhs.nl Fri Apr 29 07:00:11 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 09:00:11 +0200 Subject: D1x license Message-ID: <4271DB7B.7080102@hhs.nl> Hi, Before moving forward with d1x I decided to review all the legal/license details. The shareware datafiles (as distributed by SUSE) come with the following text: --- The Shareware Descent Data Files are freely distributable to anyone and everyone so long as they are distributed in UNMODIFIED FORM and no fees are charged. All the files must be distributed together. --- The "no fees are charged" part worries me, would this create trouble for people who would wish to create and sell Fedora Extras CD's? Or are the costs in this case for the CD and the labour burning the CD and not for the software on it since this is freely available from the net? Since the shareware files have been distributed on CD by SUSE for a long time I think this is not a problem but what do you think? The descent source itself comes under a license from Parallax: --- THE COMPUTER CODE CONTAINED HEREIN IS THE SOLE PROPERTY OF PARALLAX SOFTWARE CORPORATION ("PARALLAX"). PARALLAX, IN DISTRIBUTING THE CODE TO END-USERS, AND SUBJECT TO ALL OF THE TERMS AND CONDITIONS HEREIN, GRANTS A ROYALTY-FREE, PERPETUAL LICENSE TO SUCH END-USERS FOR USE BY SUCH END-USERS IN USING, DISPLAYING, AND CREATING DERIVATIVE WORKS THEREOF, SO LONG AS SUCH USE, DISPLAY OR CREATION IS FOR NON-COMMERCIAL, ROYALTY OR REVENUE FREE PURPOSES. IN NO EVENT SHALL THE END-USER USE THE COMPUTER CODE CONTAINED HEREIN FOR REVENUE-BEARING PURPOSES. THE END-USER UNDERSTANDS AND AGREES TO THE TERMS HEREIN AND ACCEPTS THE SAME BY USE OF THIS FILE. COPYRIGHT 1993-1998 PARALLAX SOFTWARE CORPORATION. ALL RIGHTS RESERVED. --- So basicly BSD-ish but with a not for commercial use clause. The d1x programmers have added the following conditions for there modifications: --- 1) By using this source you are agreeing to these terms. 2) D1x and derived works may only be modified if ONE of the following is done: a) The modified version is placed under this license. The source code used to create the modified version is freely and publicly available under this license. b) The modified version is only used by the developer. 3) D1X IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. --- Making the total license GPL-ish but with a not for commercial use clause. Which basicly means that this is close but not an opensource license. Thus my question becomes is this license close enough to allow inclusion into Fedora Extras? Regards, Hans From nphilipp at redhat.com Fri Apr 29 07:53:09 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 29 Apr 2005 09:53:09 +0200 Subject: Help needed: bzflag doesn't work properly on FC4test/Rawhide Message-ID: <1114761189.5921.18.camel@wombat.tiptoe.de> Hi all, I've got a problem with the bzflag package, namely that it compiles but doesn't work properly -- it doesn't crash, but among other things other players can't see your shots and don't get hit by them either. See the bug report upstream at SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=1191085&group_id=3248&atid=103248 I suspect that the problem is exhibited by the use of the new gcc-4.0 compiler, but I'm not a compiler expert either ;-). The only thing I found suspicious when building the thing is some warnings where return values were ignored and some other warnings about inlined C++ template code that doesn't return anything where a return value is expected. Unfortunately these latter warnings are only so much gibberish to me, I'm not able to deduce the lines of code where the problems originate. But then the real problem may lie somewhere else entirely, who knows? If someone with more clues about problems stemming from a gcc-3.4 -> gcc-4.0 transition could take a look at this it would be great. TIA, 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 mpeters at mac.com Fri Apr 29 07:58:25 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 29 Apr 2005 00:58:25 -0700 Subject: D1x license In-Reply-To: <4271DB7B.7080102@hhs.nl> References: <4271DB7B.7080102@hhs.nl> Message-ID: <1114761505.17483.10.camel@fc4t2.mpeters.local> On Fri, 2005-04-29 at 09:00 +0200, Hans de Goede wrote: > Hi, > > Before moving forward with d1x I decided to review all the legal/license > details. The shareware datafiles (as distributed by SUSE) come with the > following text: > --- > The Shareware Descent Data Files are freely distributable to anyone and > everyone so long as they are distributed in UNMODIFIED FORM and no fees > are charged. All the files must be distributed together. Who owns the datafiles? They are probably best to contact and find out. Descent? I think I bought that game for Linux at a used bookstore a few years back, and it didn't work because my RH was too knew (I was running 8, I think it wanted 6.x) From j.w.r.degoede at hhs.nl Fri Apr 29 08:24:41 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 10:24:41 +0200 Subject: D1x license In-Reply-To: <1114761505.17483.10.camel@fc4t2.mpeters.local> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> Message-ID: <4271EF49.90708@hhs.nl> Michael A. Peters wrote: > On Fri, 2005-04-29 at 09:00 +0200, Hans de Goede wrote: > >>Hi, >> >>Before moving forward with d1x I decided to review all the legal/license >>details. The shareware datafiles (as distributed by SUSE) come with the >>following text: >>--- >>The Shareware Descent Data Files are freely distributable to anyone and >>everyone so long as they are distributed in UNMODIFIED FORM and no fees >>are charged. All the files must be distributed together. > > > Who owns the datafiles? > They are probably best to contact and find out. > AFAIK Parallax I'll see if I can contact them, what about the licence for the engine source? > Descent? > I think I bought that game for Linux at a used bookstore a few years > back, and it didn't work because my RH was too knew (I was running 8, I > think it wanted 6.x) > The source release works fine on FC3, I'm currently patching it up to build with gcc4 for FC4. Regards, Hans From fkooman at tuxed.net Fri Apr 29 09:36:21 2005 From: fkooman at tuxed.net (F. Kooman) Date: Fri, 29 Apr 2005 11:36:21 +0200 Subject: use of gtk-update-icon-cache? Message-ID: <1114767381.4827.7.camel@dilithium.bromstraat.net> I was browsing through some of the Fedora spec files and wondered why in gedit.spec for example there is this section: %post # update icon themes touch %{_datadir}/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor fi I'm not sure why it's there, the gedit package doesn't use /usr/share/icons/hicolor to store it's icons, so an update (in this directory) is not really necessary? I'm asking this because I'm trying to build my own Gossip RPMs (and it's missing it's menu entry icon just after installation). After rebooting (or just a new login) the icon shows up. Fran?ois -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From fedora at leemhuis.info Fri Apr 29 10:07:48 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 29 Apr 2005 12:07:48 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: <1114767381.4827.7.camel@dilithium.bromstraat.net> References: <1114767381.4827.7.camel@dilithium.bromstraat.net> Message-ID: <1114769268.8958.20.camel@thl.ct.heise.de> I planed this mail for the weekend after a bit more investigation in this area, but while on topic I better start now: Am Freitag, den 29.04.2005, 11:36 +0200 schrieb F. Kooman: > %post > # update icon themes > touch %{_datadir}/icons/hicolor > if [ -x /usr/bin/gtk-update-icon-cache ]; then > /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor > fi AFAIK we also need to do this in %post and %postun in every FC4/devel extras-package that installs something into "%{_datadir}/icons/*/" so the cache files found there. After a quick rough look into cvs it seems at least this packages need the patch found below: abiword amarok clearlooks djvulibre enigma fyre gnome-themes-extras gwenview kid3 kile kover ksensors ktrack libkipi notecase psi revelation showimg TeXmacs tuxpaint xcin xfcalendar xfce4-iconbox xfce4-mixer xfce4-panel xfce4-session xfce-mcs-manager xfce-utils xfdesktop xffm xfprint xfwm4 Proposed patch (this one against revelation/devel) ########################## Index: revelation.spec =================================================================== RCS file: /cvs/extras/rpms/revelation/devel/revelation.spec,v retrieving revision 1.8 diff -u -r1.8 revelation.spec --- revelation.spec 2 Apr 2005 11:32:55 -0000 1.8 +++ revelation.spec 29 Apr 2005 10:01:34 -0000 @@ -4,7 +4,7 @@ Summary: Password manager for GNOME 2 Name: revelation Version: 0.4.3 -Release: 2 +Release: 3 License: GPL Group: Applications/Productivity Source: ftp://oss.codepoet.no/revelation/revelation-0.4.3.tar.bz2 @@ -26,9 +26,11 @@ BuildRequires: cracklib BuildRequires: words BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot-%(%{__id_u} -n) -Requires(post): GConf2 shared-mime-info desktop-file-utils -Requires(preun): GConf2 +Requires(post): GConf2 shared-mime-info desktop-file-utils +Requires(post): gtk2 >= 2.6 +Requires(preun): GConf2 Requires(postun): shared-mime-info desktop-file-utils +Requires(postun): gtk2 >= 2.6 %description Revelation is a password manager. It organizes accounts in @@ -60,7 +62,10 @@ gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/%{name}.schemas &>/dev/null || : update-mime-database %{_datadir}/mime > /dev/null 2>&1 || : update-desktop-database %{_datadir}/applications > /dev/null 2>&1 || : - +touch --no-create %{_datadir}/icons/hicolor || : +if [ -x /usr/bin/gtk-update-icon-cache ]; then + gtk-update-icon-cache -q %{_datadir}/icons/hicolor || : +fi %preun export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` @@ -69,7 +74,10 @@ %postun update-mime-database %{_datadir}/mime > /dev/null 2>&1 || : update-desktop-database %{_datadir}/applications > /dev/null 2>&1 || : - +touch --no-create %{_datadir}/icons/hicolor || : +if [ -x /usr/bin/gtk-update-icon-cache ]; then + gtk-update-icon-cache -q %{_datadir}/icons/hicolor || : +fi %clean %{__rm} -rf %{buildroot} @@ -101,6 +109,9 @@ %ghost %{python_sitelib}/revelation/datahandler/*.pyo %changelog +* Wed Apr 27 2005 Thorsten Leemhuis 0.4.3-3 +- Update the GTK+ theme icon cache on (un)install + * Sat Apr 02 2005 Thorsten Leemhuis 0:0.4.3-2 - Devel rebuild ########################## Any comments on that patch? CU thl From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 29 10:09:23 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 29 Apr 2005 12:09:23 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <42712EA1.2050401@hhs.nl> References: <42712EA1.2050401@hhs.nl> Message-ID: <20050429120923.0fd0a318@python2> Hi, I just tried to recompile it for FC Development x86_64 and got this error : [...] gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 -DGLIDE_HW_TRI_SETUP=1 - DFX_GLIDE_NAPALM=1 -DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH - DFX_STATIC_BUILD -DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/ glide3/src -I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/ minihwc -I. -I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc - I../../../../swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- unknown-pragmas -Wno-unused-value -Wno-unused -Wno-missing-noreturn -Wp,- MD,.deps/gsplash.pp -c ../../../../h5/glide3/src/gsplash.c -fPIC -DPIC - o .libs/gsplash.o In file included from ../../../../h5/glide3/src/ gsplash.c:170: ../../../../h5/glide3/src/fxglide.h:2104:4: error: #error "P6 Fencing code needs to be added for this compiler" make[3]: *** [gsplash.lo] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/Glide3/ build-5/h5/glide3/src' Not sure what should be done... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.34 2.54 2.38 From enrico.scholz at informatik.tu-chemnitz.de Fri Apr 29 11:16:44 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Apr 2005 13:16:44 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: <1114767381.4827.7.camel@dilithium.bromstraat.net> (F. Kooman's message of "Fri, 29 Apr 2005 11:36:21 +0200") References: <1114767381.4827.7.camel@dilithium.bromstraat.net> Message-ID: <87pswdestf.fsf@kosh.bigo.ensc.de> fkooman at tuxed.net ("F. Kooman") writes: > %post > # update icon themes > touch %{_datadir}/icons/hicolor > if [ -x /usr/bin/gtk-update-icon-cache ]; then > /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor > fi Stop, before applying such scriptlets: There must be appended an '|| :' after the 'touch' and the 'gtk-update-icon-cache' command. When %_datadir is in %_netsharedpath and mounted read-only therefore, the command and the entire scriptlet will fail. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ivazquez at ivazquez.net Fri Apr 29 11:36:32 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Apr 2005 07:36:32 -0400 Subject: Help needed: bzflag doesn't work properly on FC4test/Rawhide In-Reply-To: <1114761189.5921.18.camel@wombat.tiptoe.de> References: <1114761189.5921.18.camel@wombat.tiptoe.de> Message-ID: <1114774592.5061.59.camel@ignacio.ignacio.lan> On Fri, 2005-04-29 at 09:53 +0200, Nils Philippsen wrote: > The only thing I > found suspicious when building the thing is some warnings where return > values were ignored and some other warnings about inlined C++ template > code that doesn't return anything where a return value is expected. I could be wrong, but it might be a problem with libstdc++-devel. It might be worth asking the maintainer of that 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 fedora at camperquake.de Fri Apr 29 11:50:09 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 29 Apr 2005 13:50:09 +0200 Subject: Request for Review: bmp-flac In-Reply-To: <1114729468.3333.12.camel@localhost.localdomain> References: <20050419145608.6ad15254@nausicaa.camperquake.de> <20050419151730.35257143.bugs.michael@gmx.net> <20050419212110.698d558b@nausicaa.camperquake.de> <20050419222344.3da5dd23.bugs.michael@gmx.net> <1114729468.3333.12.camel@localhost.localdomain> Message-ID: <20050429135009.023b785e@nausicaa.camperquake.de> Hi. "Tom 'spot' Callaway" wrote: > Patch attached to resolve this blocker. Confirmed that it works (with > Dave Grohl's 1993 pre Foo Fighters demo tape!). Hmmm. I had planned to retract this bmp-flac version (and write a new from scratch), since there seem to be some more problems with this code apart from not supporting "file:///" style URLs. But I have no problems with inporting it until bmp-flac2 is ready to roll. -- 'cause I've got Schweden on my mind. From fedora at camperquake.de Fri Apr 29 11:56:04 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 29 Apr 2005 13:56:04 +0200 Subject: General gcc4.0 porting guide Message-ID: <20050429135604.17409f66@nausicaa.camperquake.de> Hi. Is there a general document showing common pitfalls when compiling a package with gcc4.0 (and how to resolve them)? For example, what is the "right" way to deal with this: int* foo; [...] ((short int*)foo)++; // gcc4 does not like this. -- The person who can smile when something goes wrong has thought of someone they can blame it all on. From nphilipp at redhat.com Fri Apr 29 12:05:31 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 29 Apr 2005 14:05:31 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <20050429135604.17409f66@nausicaa.camperquake.de> References: <20050429135604.17409f66@nausicaa.camperquake.de> Message-ID: <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-04-29 at 13:56 +0200, Ralf Ertzinger wrote: > Hi. > > Is there a general document showing common pitfalls when compiling a > package with gcc4.0 (and how to resolve them)? > > For example, what is the "right" way to deal with this: > > int* foo; > > [...] > ((short int*)foo)++; // gcc4 does not like this. 1) Fix the code in question (why is there a cast to short) ;-) 2) perhaps: *foo = ((short int) (*foo)) + 1; 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 fedora at camperquake.de Fri Apr 29 12:10:29 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 29 Apr 2005 14:10:29 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20050429141029.1f291c08@nausicaa.camperquake.de> Hi. Nils Philippsen wrote: > > For example, what is the "right" way to deal with this: > > > > int* foo; > > > > [...] > > ((short int*)foo)++; // gcc4 does not like this. > > 1) Fix the code in question (why is there a cast to short) ;-) > > 2) perhaps: > > *foo = ((short int) (*foo)) + 1; Unless I am very much mistaken (my C-fu is weak), this is not the same. The code I posted is pointer arithmetic. -- "You didn't want software written by a calm, happy, non-paranoid individual to be answering port 25 anyway." -- Anthony DeBoer From j.w.r.degoede at hhs.nl Fri Apr 29 12:15:15 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 14:15:15 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42722553.5060701@hhs.nl> Nils Philippsen wrote: > On Fri, 2005-04-29 at 13:56 +0200, Ralf Ertzinger wrote: > >>Hi. >> >>Is there a general document showing common pitfalls when compiling a >>package with gcc4.0 (and how to resolve them)? >> >>For example, what is the "right" way to deal with this: >> >>int* foo; >> >>[...] >>((short int*)foo)++; // gcc4 does not like this. > > > 1) Fix the code in question (why is there a cast to short) ;-) > > 2) perhaps: > > *foo = ((short int) (*foo)) + 1; No, the original code moved the ptr your code instead changes the contents of what is pointed to. Correct would be: foo = (int *)((short int *)foo + 1); Regards, Hans From mitr at volny.cz Fri Apr 29 12:12:25 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 29 Apr 2005 14:12:25 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <20050429135604.17409f66@nausicaa.camperquake.de> References: <20050429135604.17409f66@nausicaa.camperquake.de> Message-ID: <20050429121220.GA20472@chrys.ms.mff.cuni.cz> On Fri, Apr 29, 2005 at 01:56:04PM +0200, Ralf Ertzinger wrote: > Hi. > > Is there a general document showing common pitfalls when compiling a > package with gcc4.0 (and how to resolve them)? There are change descriptions on gcc.gnu.org. > For example, what is the "right" way to deal with this: > > int* foo; > > [...] > ((short int*)foo)++; // gcc4 does not like this. foo = (short int *)(foo + 1); Mirek From j.w.r.degoede at hhs.nl Fri Apr 29 12:22:02 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 14:22:02 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <20050429120923.0fd0a318@python2> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> Message-ID: <427226EA.6010900@hhs.nl> Thanks for trying it out, x86_64 support is as said in the specfile untested. The code in question is: #elif defined(__GNUC__) && defined(__i386__) /* * This is the __linux__ code. */ #define P6FENCE \ asm("xchg %%eax, %0" : : "m" (_GlideRoot.p6Fencer) : "eax"); #else # error "P6 Fencing code needs to be added for this compiler" #endif Now the questions are: -what symbol gets defined instead of __i386__ for x86_64 -is the asm code correct for x86_64 Regards, Hans Matthias Saou wrote: > Hi, > > I just tried to recompile it for FC Development x86_64 and got this error : > > [...] > gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - > ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - > DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 -DGLIDE_HW_TRI_SETUP=1 - > DFX_GLIDE_NAPALM=1 -DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH - > DFX_STATIC_BUILD -DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/ > glide3/src -I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/ > minihwc -I. -I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc - > I../../../../swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - > pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- > unknown-pragmas -Wno-unused-value -Wno-unused -Wno-missing-noreturn -Wp,- > MD,.deps/gsplash.pp -c ../../../../h5/glide3/src/gsplash.c -fPIC -DPIC - > o .libs/gsplash.o In file included from ../../../../h5/glide3/src/ > gsplash.c:170: ../../../../h5/glide3/src/fxglide.h:2104:4: error: #error > "P6 Fencing code needs to be added for this compiler" make[3]: *** > [gsplash.lo] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/Glide3/ > build-5/h5/glide3/src' > > Not sure what should be done... > > Matthias > From j.w.r.degoede at hhs.nl Fri Apr 29 12:22:52 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 14:22:52 +0200 Subject: Help wanted with converting 1 line asm i386->x86_64 Message-ID: <4272271C.8050208@hhs.nl> Hi, The code in question is: #elif defined(__GNUC__) && defined(__i386__) /* * This is the __linux__ code. */ #define P6FENCE \ asm("xchg %%eax, %0" : : "m" (_GlideRoot.p6Fencer) : "eax"); #else # error "P6 Fencing code needs to be added for this compiler" #endif Now the questions are: -what symbol gets defined instead of __i386__ for x86_64 -is the asm code correct for x86_64 Regards, Hans From j.w.r.degoede at hhs.nl Fri Apr 29 12:25:27 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 14:25:27 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <20050429121220.GA20472@chrys.ms.mff.cuni.cz> References: <20050429135604.17409f66@nausicaa.camperquake.de> <20050429121220.GA20472@chrys.ms.mff.cuni.cz> Message-ID: <427227B7.9070408@hhs.nl> Miloslav Trmac wrote: > On Fri, Apr 29, 2005 at 01:56:04PM +0200, Ralf Ertzinger wrote: > >>Hi. >> >>Is there a general document showing common pitfalls when compiling a >>package with gcc4.0 (and how to resolve them)? > > There are change descriptions on gcc.gnu.org. > > >>For example, what is the "right" way to deal with this: >> >>int* foo; >> >>[...] >>((short int*)foo)++; // gcc4 does not like this. > > foo = (short int *)(foo + 1); > Mirek Wrong (again) people please don't try to help unless you know how pointer arithmetic works in C. foo is a int *, so your assignment will give an invalid ptr type warning if not an error. also since you first increment foo and then cast it foo will be increased by 4 (sizeof(int) == 4) where the original code increased it by 2. Regards, Hans From mitr at volny.cz Fri Apr 29 12:28:59 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 29 Apr 2005 14:28:59 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <427227B7.9070408@hhs.nl> References: <20050429135604.17409f66@nausicaa.camperquake.de> <20050429121220.GA20472@chrys.ms.mff.cuni.cz> <427227B7.9070408@hhs.nl> Message-ID: <20050429122859.GB20472@chrys.ms.mff.cuni.cz> On Fri, Apr 29, 2005 at 02:25:27PM +0200, Hans de Goede wrote: > Miloslav Trmac wrote: > >foo = (short int *)(foo + 1); > Wrong (again) people please don't try to help unless you know how > pointer arithmetic works in C. Ooops... People please don't assume ignorance when it can be explained by lack of attention :) Let me use this space to point out that the code is not portable; accessing unaligned pointers can be a fatal error on some architectures. Mirek From bugs.michael at gmx.net Fri Apr 29 13:06:49 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Apr 2005 15:06:49 +0200 Subject: sponsors still needed for new packages, extras not advertised on fedorawebsite? In-Reply-To: <427137B3.9080009@hhs.nl> References: <427137B3.9080009@hhs.nl> Message-ID: <20050429150649.7960a12c.bugs.michael@gmx.net> On Thu, 28 Apr 2005 21:21:23 +0200, Hans de Goede wrote: > Hi, > > AFAIK sponsorship is no longer needed to get CVS access, instead one > should go through the new webinterface, right? (I already have CVS > access, just checking) No. People can sign up via the web interface, but still need a sponsor to approve them before the system creates the account. > What about new packages, I see a lot of review requests for new packages > on this list without first seeing a sponsor request. So are sponsors > still needed for new packages? Or is the idea that if someone reviews it > and approves it that he then also automaticly sponsers it, in that case > shouldn't: http://fedoraproject.org/wiki/NewPackageProcess be updated? That page in the Wiki is under review and will change, because it is ambiguous and confusing, both with regard to the used terminology and the overall process. The described process was supposed to be an interim process only anyway. Perhaps you've noticed the thread about it a few days ago. * There is no such thing as a "package sponsor". We use the notion of "sponsoring" only for CVS access. * For a new package you need somebody, who _approves_ your package explicitly by posting a message to fedora-extras-commits list. Explicit approval is necessary before a new package may be built. It need not be your CVS account sponsor to approve your package. It must be somebody with Fedora Extras CVS access and, for instance, could also be your package co-maintainer. Preferably (in my point of view), the approval is posted before or shortly after the new package is imported into CVS, but must be posted before a first build is requested. The person, who approves your package, must be the _primary reviewer_ of your package. There is no guarantee that other contributors comment on CVS commits, in particular not during times of high list traffic. So, the primary reviewer of your package ought to feel good about approving your new package and, for instance, apply security related checks, take a look at the licencing, and look for oddities with regard to current packaging policies and guidelines _prior_ to approval. Security related checks (upstream locations, tarball checksums, project status, maybe see whether the software is included in other big distributions) are something every package maintainer ought to be familiar with, as he will be responsible for the package and its upgrades. To find a primary reviewer, who volunteers to approve your package, post to fedora-extras-list, describe the software you packaged and provide a link to the src.rpm. * An approval notification sent to fedora-extras-commits list should use "Subject: APPROVED: packagename" and list the names of the person, who approved it and who will maintain it. From bugs.michael at gmx.net Fri Apr 29 13:11:29 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Apr 2005 15:11:29 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: <87pswdestf.fsf@kosh.bigo.ensc.de> References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <87pswdestf.fsf@kosh.bigo.ensc.de> Message-ID: <20050429151129.372c4f78.bugs.michael@gmx.net> On Fri, 29 Apr 2005 13:16:44 +0200, Enrico Scholz wrote: > fkooman at tuxed.net ("F. Kooman") writes: > > > %post > > # update icon themes > > touch %{_datadir}/icons/hicolor > > if [ -x /usr/bin/gtk-update-icon-cache ]; then > > /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor > > fi > > Stop, before applying such scriptlets: There must be appended an '|| :' > after the 'touch' and the 'gtk-update-icon-cache' command. When %_datadir > is in %_netsharedpath and mounted read-only therefore, the command and > the entire scriptlet will fail. Package installation would fail miserably in that case, because the package could not install any files into %_datadir beforehand. For exported file-systems, you would only install packages on the file server, where the install locations are not read-only. Or what does your scenario look like? From enrico.scholz at informatik.tu-chemnitz.de Fri Apr 29 13:11:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Apr 2005 15:11:12 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <20050429135604.17409f66@nausicaa.camperquake.de> (Ralf Ertzinger's message of "Fri, 29 Apr 2005 13:56:04 +0200") References: <20050429135604.17409f66@nausicaa.camperquake.de> Message-ID: <87ll71enin.fsf@kosh.bigo.ensc.de> fedora at camperquake.de (Ralf Ertzinger) writes: > Is there a general document showing common pitfalls when compiling a > package with gcc4.0 (and how to resolve them)? /usr/share/doc/gcc-*4* contains some documents dealing with this. > For example, what is the "right" way to deal with this: Finding the developer of this code and hitting him with a copy of the C standard. > int* foo; > > [...] > ((short int*)foo)++; // gcc4 does not like this. | foo = (int *)((short int *)(foo) + 1); should work. But depending on this what the author wants to achieve, more elegant solutions are probably possible. Especially, because the code with pointer arithmetic might be less efficient than such with perfect aligned variables. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 29 13:32:02 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 29 Apr 2005 15:32:02 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <42722553.5060701@hhs.nl> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> <42722553.5060701@hhs.nl> Message-ID: <20050429153202.2a570ca5@python2> Hans de Goede wrote : > >>[...] > >>((short int*)foo)++; // gcc4 does not like this. > > > > > > 1) Fix the code in question (why is there a cast to short) ;-) > > > > 2) perhaps: > > > > *foo = ((short int) (*foo)) + 1; > > No, the original code moved the ptr your code instead changes the > contents of what is pointed to. > > Correct would be: > foo = (int *)((short int *)foo + 1); Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the proper fix for this be, then? *((unsigned short*)data)++ = \ ((CLIP(r_l) & 0xf8) << 8) | \ ((CLIP(g_l) & 0xfc) << 3) | \ ((CLIP(b_l) & 0xf8) >> 3); Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.89 0.76 0.53 From nphilipp at redhat.com Fri Apr 29 13:45:57 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 29 Apr 2005 15:45:57 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <20050429122859.GB20472@chrys.ms.mff.cuni.cz> References: <20050429135604.17409f66@nausicaa.camperquake.de> <20050429121220.GA20472@chrys.ms.mff.cuni.cz> <427227B7.9070408@hhs.nl> <20050429122859.GB20472@chrys.ms.mff.cuni.cz> Message-ID: <1114782357.4582.50.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-04-29 at 14:28 +0200, Miloslav Trmac wrote: > On Fri, Apr 29, 2005 at 02:25:27PM +0200, Hans de Goede wrote: > > Miloslav Trmac wrote: > > >foo = (short int *)(foo + 1); > > Wrong (again) people please don't try to help unless you know how > > pointer arithmetic works in C. > Ooops... > People please don't assume ignorance when it can be explained by > lack of attention :) Same for me. Though you could argue that our lack of attention in that case can be counted as ignorance as well ;-). 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 ivazquez at ivazquez.net Fri Apr 29 14:05:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Apr 2005 10:05:00 -0400 Subject: General gcc4.0 porting guide In-Reply-To: <20050429153202.2a570ca5@python2> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> <42722553.5060701@hhs.nl> <20050429153202.2a570ca5@python2> Message-ID: <1114783500.17067.5.camel@ignacio.ignacio.lan> On Fri, 2005-04-29 at 15:32 +0200, Matthias Saou wrote: > Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the > proper fix for this be, then? > > *((unsigned short*)data)++ = \ > ((CLIP(r_l) & 0xf8) << 8) | \ > ((CLIP(g_l) & 0xfc) << 3) | \ > ((CLIP(b_l) & 0xf8) >> 3); Possibly: *((unsigned short*)data) = \ ((CLIP(r_l) & 0xf8) << 8) | \ ((CLIP(g_l) & 0xfc) << 3) | \ ((CLIP(b_l) & 0xf8) >> 3); data += sizeof(unsigned short) / sizeof(*data); or: register unsigned short newdata = \ ((CLIP(r_l) & 0xf8) << 8) | \ ((CLIP(g_l) & 0xfc) << 3) | \ ((CLIP(b_l) & 0xf8) >> 3); data++ = (unsigned char)((newdata >> 8) & 0xff); data++ = (unsigned char)(newdata & 0xff); -- 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 Apr 29 14:08:58 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Apr 2005 09:08:58 -0500 Subject: D1x license In-Reply-To: <4271EF49.90708@hhs.nl> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> Message-ID: <1114783738.3333.28.camel@localhost.localdomain> On Fri, 2005-04-29 at 10:24 +0200, Hans de Goede wrote: > AFAIK Parallax I'll see if I can contact them, what about the licence > for the engine source? The "Free for non-commercial use" license is currently pending legal review. SuSE is very very very good at shipping things that wouldn't remotely be considered open source, so we can't use them as precedent. It sure would help if we could find something else shipped in Fedora Core that had a "not for commercial use" clause. ~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 fedora at camperquake.de Fri Apr 29 14:09:36 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 29 Apr 2005 16:09:36 +0200 Subject: D1x license In-Reply-To: <1114783738.3333.28.camel@localhost.localdomain> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> Message-ID: <20050429140936.GA21470@ryoko.camperquake.de> On Fri, Apr 29, 2005 at 09:08:58AM -0500, Tom 'spot' Callaway wrote: > It sure would help if we could find something else shipped in Fedora > Core that had a "not for commercial use" clause. Which would result in the removal of said package? From enrico.scholz at informatik.tu-chemnitz.de Fri Apr 29 14:10:20 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Apr 2005 16:10:20 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <20050429153202.2a570ca5@python2> (Matthias Saou's message of "Fri, 29 Apr 2005 15:32:02 +0200") References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> <42722553.5060701@hhs.nl> <20050429153202.2a570ca5@python2> Message-ID: <873bt9eks3.fsf@kosh.bigo.ensc.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> >>((short int*)foo)++; // gcc4 does not like this. >> ... >> Correct would be: >> foo = (int *)((short int *)foo + 1); > > Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the > proper fix for this be, then? > > *((unsigned short*)data)++ = \ > ((CLIP(r_l) & 0xf8) << 8) | \ > ((CLIP(g_l) & 0xfc) << 3) | \ > ((CLIP(b_l) & 0xf8) >> 3); When this happens in a loop, I would write: | uint16_t *data_c = (uint16_t *)(data); | | for (....) { | ... | *data_c++ = ((CLIP...)); // FIXME: what's about endianess? | } | | data = (uint32_t *)(data_c); // FIXME: what's about aligment?? But it would be much better, to use a fitting datastructure for 'data' instead of a plain uint32_t[]. But that's an upstream but not packager task. 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 Fri Apr 29 13:40:18 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Apr 2005 15:40:18 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: <20050429151129.372c4f78.bugs.michael@gmx.net> (Michael Schwendt's message of "Fri, 29 Apr 2005 15:11:29 +0200") References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <87pswdestf.fsf@kosh.bigo.ensc.de> <20050429151129.372c4f78.bugs.michael@gmx.net> Message-ID: <877jilem65.fsf@kosh.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> > %post >> > # update icon themes >> > touch %{_datadir}/icons/hicolor >> > if [ -x /usr/bin/gtk-update-icon-cache ]; then >> > /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor >> > fi >> >> Stop, before applying such scriptlets: There must be appended an '|| :' >> after the 'touch' and the 'gtk-update-icon-cache' command. When %_datadir >> is in %_netsharedpath and mounted read-only therefore, the command and >> the entire scriptlet will fail. > > Package installation would fail miserably in that case, because the > package could not install any files into %_datadir beforehand. Wrong; you missed the %_netsharedpath part ;) The scenario is this: Host A: * exports /usr via NFS * /usr is mounted read-write there * installs the superset of all packages on hosts X, Y and Z Hosts X, Y, Z: * mounts A:/usr readonly * has a %_netsharedpath of /usr Now, when A installs a package owning /usr/bin/foo it will be installed physically and is available on X, Y and Z. When X installs the same package, it will be added to the database but not installed physically. E.g.: | $ rpm -qs | net shared /usr/bin/foo > For exported file-systems, you would only install packages on the file > server, where the install locations are not read-only. You miss the fact that most packages ship files under /etc or /var also which can not be shared, do registration tasks in the %scriptlets or are dependencies of other packages. Therefore, packages must be installed on both the fileserver and the clients. jbj wants to solve this by attaching actions to certain filetypes (and obsoleting most %scripts by this). I am a bit sceptical about this and would prefer a lower level mechanism (like this in bug #51193). See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=51193 for more details or search for 'mount' and me in bugzilla ;) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tcallawa at redhat.com Fri Apr 29 14:20:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Apr 2005 09:20:09 -0500 Subject: D1x license In-Reply-To: <20050429140936.GA21470@ryoko.camperquake.de> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429140936.GA21470@ryoko.camperquake.de> Message-ID: <1114784409.3333.30.camel@localhost.localdomain> On Fri, 2005-04-29 at 16:09 +0200, Ralf Ertzinger wrote: > On Fri, Apr 29, 2005 at 09:08:58AM -0500, Tom 'spot' Callaway wrote: > > > It sure would help if we could find something else shipped in Fedora > > Core that had a "not for commercial use" clause. > > Which would result in the removal of said package? Its possible, it might also give us precedent for legal to let us do the same in Extras. ~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 enrico.scholz at informatik.tu-chemnitz.de Fri Apr 29 13:40:18 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Apr 2005 15:40:18 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: <20050429151129.372c4f78.bugs.michael@gmx.net> (Michael Schwendt's message of "Fri, 29 Apr 2005 15:11:29 +0200") References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <87pswdestf.fsf@kosh.bigo.ensc.de> <20050429151129.372c4f78.bugs.michael@gmx.net> Message-ID: <877jilem65.fsf@kosh.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> > %post >> > # update icon themes >> > touch %{_datadir}/icons/hicolor >> > if [ -x /usr/bin/gtk-update-icon-cache ]; then >> > /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor >> > fi >> >> Stop, before applying such scriptlets: There must be appended an '|| :' >> after the 'touch' and the 'gtk-update-icon-cache' command. When %_datadir >> is in %_netsharedpath and mounted read-only therefore, the command and >> the entire scriptlet will fail. > > Package installation would fail miserably in that case, because the > package could not install any files into %_datadir beforehand. Wrong; you missed the %_netsharedpath part ;) The scenario is this: Host A: * exports /usr via NFS * /usr is mounted read-write there * installs the superset of all packages on hosts X, Y and Z Hosts X, Y, Z: * mounts A:/usr readonly * has a %_netsharedpath of /usr Now, when A installs a package owning /usr/bin/foo it will be installed physically and is available on X, Y and Z. When X installs the same package, it will be added to the database but not installed physically. E.g.: | $ rpm -qs | net shared /usr/bin/foo > For exported file-systems, you would only install packages on the file > server, where the install locations are not read-only. You miss the fact that most packages ship files under /etc or /var also which can not be shared, do registration tasks in the %scriptlets or are dependencies of other packages. Therefore, packages must be installed on both the fileserver and the clients. jbj wants to solve this by attaching actions to certain filetypes (and obsoleting most %scripts by this). I am a bit sceptical about this and would prefer a lower level mechanism (like this in bug #51193). See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=51193 for more details or search for 'mount' and me in bugzilla ;) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mattdm at mattdm.org Fri Apr 29 14:36:20 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 29 Apr 2005 10:36:20 -0400 Subject: D1x license In-Reply-To: <1114783738.3333.28.camel@localhost.localdomain> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> Message-ID: <20050429143620.GA3034@jadzia.bu.edu> On Fri, Apr 29, 2005 at 09:08:58AM -0500, Tom 'spot' Callaway wrote: > It sure would help if we could find something else shipped in Fedora > Core that had a "not for commercial use" clause. I have a vague memory of some package being dropped for having exactly that clause. I'll see if I can think of what it was.... Anyway, I think anything with such a license shouldn't be in Fedora Extras. It'll severely limit the distribution. If need be, we can have a Fedora Non-Free. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 72 degrees Fahrenheit. From tcallawa at redhat.com Fri Apr 29 14:55:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Apr 2005 09:55:19 -0500 Subject: D1x license In-Reply-To: <20050429143620.GA3034@jadzia.bu.edu> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429143620.GA3034@jadzia.bu.edu> Message-ID: <1114786519.3333.42.camel@localhost.localdomain> On Fri, 2005-04-29 at 10:36 -0400, Matthew Miller wrote: > On Fri, Apr 29, 2005 at 09:08:58AM -0500, Tom 'spot' Callaway wrote: > > It sure would help if we could find something else shipped in Fedora > > Core that had a "not for commercial use" clause. > > I have a vague memory of some package being dropped for having exactly that > clause. I'll see if I can think of what it was.... > > Anyway, I think anything with such a license shouldn't be in Fedora Extras. > It'll severely limit the distribution. If need be, we can have a Fedora > Non-Free. A LOT of scientific and mathematical code is licensed as "Free for non-commercial use". If we can't include it in FE, I'd understand. I'll just have to email a lot of maintainers to beg for a license change. ~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 j.w.r.degoede at hhs.nl Fri Apr 29 15:05:45 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 17:05:45 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <873bt9eks3.fsf@kosh.bigo.ensc.de> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> <42722553.5060701@hhs.nl> <20050429153202.2a570ca5@python2> <873bt9eks3.fsf@kosh.bigo.ensc.de> Message-ID: <42724D49.6080202@hhs.nl> Enrico Scholz wrote: > thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: > > >>>>>((short int*)foo)++; // gcc4 does not like this. >>> >>>... >>>Correct would be: >>>foo = (int *)((short int *)foo + 1); >> >>Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the >>proper fix for this be, then? >> >> *((unsigned short*)data)++ = \ >> ((CLIP(r_l) & 0xf8) << 8) | \ >> ((CLIP(g_l) & 0xfc) << 3) | \ >> ((CLIP(b_l) & 0xf8) >> 3); > > > When this happens in a loop, I would write: > > | uint16_t *data_c = (uint16_t *)(data); > | > | for (....) { > | ... > | *data_c++ = ((CLIP...)); // FIXME: what's about endianess? > | } > | > | data = (uint32_t *)(data_c); // FIXME: what's about aligment?? > > Agreed and if this is not in a loop you would need to write: { (unsigned short*)p = (unsigned short*)data; *p = ((CLIP(....... ); data = (date_type *)((unsigned short*)data + 1); } > But it would be much better, to use a fitting datastructure for 'data' > instead of a plain uint32_t[]. But that's an upstream but not packager > task. > data looks to me to be 16bpp 565 RGB pixel data, so a structure isn't really going to help and endianness is not a problem. Also alignment isn't an issue since data probably points to some pixel data which can have different formats and this code is used in the 16bpp 565 rgb format case, so all accesses to data will be short based in this case, hence no aligment problem. Regards, Hans From j.w.r.degoede at hhs.nl Fri Apr 29 15:08:01 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 17:08:01 +0200 Subject: General gcc4.0 porting guide In-Reply-To: <1114783500.17067.5.camel@ignacio.ignacio.lan> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> <42722553.5060701@hhs.nl> <20050429153202.2a570ca5@python2> <1114783500.17067.5.camel@ignacio.ignacio.lan> Message-ID: <42724DD1.3070406@hhs.nl> Ignacio Vazquez-Abrams wrote: > On Fri, 2005-04-29 at 15:32 +0200, Matthias Saou wrote: > >>Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the >>proper fix for this be, then? >> >> *((unsigned short*)data)++ = \ >> ((CLIP(r_l) & 0xf8) << 8) | \ >> ((CLIP(g_l) & 0xfc) << 3) | \ >> ((CLIP(b_l) & 0xf8) >> 3); > > > Possibly: > > *((unsigned short*)data) = \ > ((CLIP(r_l) & 0xf8) << 8) | \ > ((CLIP(g_l) & 0xfc) << 3) | \ > ((CLIP(b_l) & 0xf8) >> 3); > data += sizeof(unsigned short) / sizeof(*data); > > or: > > register unsigned short newdata = \ > ((CLIP(r_l) & 0xf8) << 8) | \ > ((CLIP(g_l) & 0xfc) << 3) | \ > ((CLIP(b_l) & 0xf8) >> 3); > data++ = (unsigned char)((newdata >> 8) & 0xff); > data++ = (unsigned char)(newdata & 0xff); > this assumes MSB endianness (so won't work on intel) and that data is a (unsigned) char *, which has not been stated. Also you probably mean "*data++ =" not "data++ =" Regards, Hans From j.w.r.degoede at hhs.nl Fri Apr 29 15:14:33 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 17:14:33 +0200 Subject: D1x license In-Reply-To: <1114783738.3333.28.camel@localhost.localdomain> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> Message-ID: <42724F59.8090009@hhs.nl> Tom 'spot' Callaway wrote: > On Fri, 2005-04-29 at 10:24 +0200, Hans de Goede wrote: > > >>AFAIK Parallax I'll see if I can contact them, what about the licence >>for the engine source? > > > The "Free for non-commercial use" license is currently pending legal > review. > > SuSE is very very very good at shipping things that wouldn't remotely be > considered open source, so we can't use them as precedent. > > It sure would help if we could find something else shipped in Fedora > Core that had a "not for commercial use" clause. > Cool, I assume that once there has been a verdict not only will the wiki be updated but there also will be a post to this list :) Thanks for looking into this. Regards, Hans From ivazquez at ivazquez.net Fri Apr 29 15:14:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Apr 2005 11:14:26 -0400 Subject: General gcc4.0 porting guide In-Reply-To: <42724DD1.3070406@hhs.nl> References: <20050429135604.17409f66@nausicaa.camperquake.de> <1114776331.4582.26.camel@gibraltar.stuttgart.redhat.com> <42722553.5060701@hhs.nl> <20050429153202.2a570ca5@python2> <1114783500.17067.5.camel@ignacio.ignacio.lan> <42724DD1.3070406@hhs.nl> Message-ID: <1114787666.17067.8.camel@ignacio.ignacio.lan> On Fri, 2005-04-29 at 17:08 +0200, Hans de Goede wrote: > Ignacio Vazquez-Abrams wrote: > > On Fri, 2005-04-29 at 15:32 +0200, Matthias Saou wrote: > > > >>Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the > >>proper fix for this be, then? > >> > >> *((unsigned short*)data)++ = \ > >> ((CLIP(r_l) & 0xf8) << 8) | \ > >> ((CLIP(g_l) & 0xfc) << 3) | \ > >> ((CLIP(b_l) & 0xf8) >> 3); > > > > > > Possibly: > > > > *((unsigned short*)data) = \ > > ((CLIP(r_l) & 0xf8) << 8) | \ > > ((CLIP(g_l) & 0xfc) << 3) | \ > > ((CLIP(b_l) & 0xf8) >> 3); > > data += sizeof(unsigned short) / sizeof(*data); > > > > or: > > > > register unsigned short newdata = \ > > ((CLIP(r_l) & 0xf8) << 8) | \ > > ((CLIP(g_l) & 0xfc) << 3) | \ > > ((CLIP(b_l) & 0xf8) >> 3); > > data++ = (unsigned char)((newdata >> 8) & 0xff); > > data++ = (unsigned char)(newdata & 0xff); > > > > this assumes MSB endianness (so won't work on intel) True enough. But easy to handle. > and that data is a (unsigned) char *, which has not been stated. I checked the code, and yes it is. > Also you probably mean "*data++ =" not "data++ =" Right, my bad. -- 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 Fri Apr 29 15:22:14 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Apr 2005 17:22:14 +0200 Subject: sponsors still needed for new packages, extras not advertised on fedorawebsite? In-Reply-To: <20050429150649.7960a12c.bugs.michael@gmx.net> References: <427137B3.9080009@hhs.nl> <20050429150649.7960a12c.bugs.michael@gmx.net> Message-ID: <42725126.9080708@hhs.nl> Michael Schwendt wrote: > * There is no such thing as a "package sponsor". We use the notion of > "sponsoring" only for CVS access. > Good! > * For a new package you need somebody, who _approves_ your package > explicitly by posting a message to fedora-extras-commits list. > Explicit approval is necessary before a new package may be built. > > It need not be your CVS account sponsor to approve your package. > It must be somebody with Fedora Extras CVS access and, for instance, > could also be your package co-maintainer. > Understood and agreed. > Preferably (in my point of view), the approval is posted before or > shortly after the new package is imported into CVS, but must be posted > before a first build is requested. Erm, not everybody has an 24hrs online private server or plenty of webspace to drop SRPMS (my isp sucks when it comes to this), so I would prefer to import a package into CVS as soon as: 1) All legal issues or cleared, iow there are no legal issues (remaining) 2) There is someone who is willing to take on the role of (primary) reviewer because he agrees the package would make a welcome addition to FE. So that it can be reviewed from CVS this has the added bonus that we start building a history, so that later on we can see why patch xyz is in the spec. This assumes that once a package has met the 2 listed requirements getting it approved is just a question of ironing out any kinks. Regards, Hans From mwiktowy at gmx.net Fri Apr 29 15:50:17 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Fri, 29 Apr 2005 11:50:17 -0400 Subject: D1x license In-Reply-To: <4271DB7B.7080102@hhs.nl> References: <4271DB7B.7080102@hhs.nl> Message-ID: <427257B9.2060008@gmx.net> Hans de Goede wrote: > Hi, > > Before moving forward with d1x I decided to review all the > legal/license details. The shareware datafiles (as distributed by > SUSE) come with the following text: > --- > The Shareware Descent Data Files are freely distributable to anyone and > everyone so long as they are distributed in UNMODIFIED FORM and no > fees are charged. All the files must be distributed together. > --- > > The "no fees are charged" part worries me, would this create trouble > for people who would wish to create and sell Fedora Extras CD's? > > Or are the costs in this case for the CD and the labour burning the CD > and not for the software on it since this is freely available from the > net? > > Since the shareware files have been distributed on CD by SUSE for a > long time I think this is not a problem but what do you think? I would think that that would be for someone who wants to sell Fedora Extras CDs to worry about. AFAIK, there is no charge for people accessing the Fedora Extras repository so it could happily reside there. If someone wants to extend the scope of Extras later into a commercial product, then they will have to make some adjustments and know what they are doing. Not putting this in just because someone may choose to come along and try to commercialize Extras without putting any thought or work into doing so seems silly to me. It would be the equivalent of not wanting to release any software written under the GPL because someone sometime in the future might want to take that software, make changes and only release the binaries. You are not in the wrong for releasing it in the first place. They are wrong for not following the conditions later. /Mike From mattdm at mattdm.org Fri Apr 29 16:08:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 29 Apr 2005 12:08:31 -0400 Subject: D1x license In-Reply-To: <1114786519.3333.42.camel@localhost.localdomain> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429143620.GA3034@jadzia.bu.edu> <1114786519.3333.42.camel@localhost.localdomain> Message-ID: <20050429160831.GA6375@jadzia.bu.edu> On Fri, Apr 29, 2005 at 09:55:19AM -0500, Tom 'spot' Callaway wrote: > A LOT of scientific and mathematical code is licensed as "Free for > non-commercial use". If we can't include it in FE, I'd understand. I'll > just have to email a lot of maintainers to beg for a license change. Yeah, I know it's a pretty common restriction. But, if we want to move more of Core to Extras (and I think pretty much everyone agrees we do), and make Extras easily selected from anaconda, Extras effectively become part of the basic distribution that vendors might want to actually provide. And having a single package in Extras with this restriction would then basically restrict all of Fedora. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 74 degrees Fahrenheit. From gdk at redhat.com Fri Apr 29 16:10:32 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 29 Apr 2005 12:10:32 -0400 (EDT) Subject: D1x license In-Reply-To: <20050429160831.GA6375@jadzia.bu.edu> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429143620.GA3034@jadzia.bu.edu> <1114786519.3333.42.camel@localhost.localdomain> <20050429160831.GA6375@jadzia.bu.edu> Message-ID: Thanks for this discussion. It gives me more useful context for my conversation next Monday with counsel. --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 Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ On Fri, 29 Apr 2005, Matthew Miller wrote: > On Fri, Apr 29, 2005 at 09:55:19AM -0500, Tom 'spot' Callaway wrote: > > A LOT of scientific and mathematical code is licensed as "Free for > > non-commercial use". If we can't include it in FE, I'd understand. I'll > > just have to email a lot of maintainers to beg for a license change. > > Yeah, I know it's a pretty common restriction. But, if we want to move more > of Core to Extras (and I think pretty much everyone agrees we do), and make > Extras easily selected from anaconda, Extras effectively become part of the > basic distribution that vendors might want to actually provide. And having a > single package in Extras with this restriction would then basically restrict > all of Fedora. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > Current office temperature: 74 degrees Fahrenheit. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From dank at kegel.com Fri Apr 29 16:09:45 2005 From: dank at kegel.com (Dan Kegel) Date: Fri, 29 Apr 2005 09:09:45 -0700 Subject: General gcc4.0 porting guide In-Reply-To: <20050429135604.17409f66@nausicaa.camperquake.de> References: <20050429135604.17409f66@nausicaa.camperquake.de> Message-ID: <42725C49.5060201@kegel.com> Ralf Ertzinger wrote: > Hi. > > Is there a general document showing common pitfalls when compiling a > package with gcc4.0 (and how to resolve them)? I have a gcc-3.4 one at http://kegel.com/gcc/gcc3.4.html and will start a gcc-4.0 one now. -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html From bugs.michael at gmx.net Fri Apr 29 16:17:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Apr 2005 18:17:38 +0200 Subject: sponsors still needed for new packages, extras not advertised on fedorawebsite? In-Reply-To: <42725126.9080708@hhs.nl> References: <427137B3.9080009@hhs.nl> <20050429150649.7960a12c.bugs.michael@gmx.net> <42725126.9080708@hhs.nl> Message-ID: <20050429181738.7cb32fdc.bugs.michael@gmx.net> On Fri, 29 Apr 2005 17:22:14 +0200, Hans de Goede wrote: > > Preferably (in my point of view), the approval is posted before or > > shortly after the new package is imported into CVS, but must be posted > > before a first build is requested. > > Erm, not everybody has an 24hrs online private server or plenty of > webspace to drop SRPMS (my isp sucks when it comes to this), Keep in mind, that a) this is still an interim process until a database adds useful tracking and b) currently, it makes no sense to import/ upload stuff, which nobody will review and approve. Exchanging spec files and relevant details about a new package should make it possible to get a preliminary "okay" from somebody, who will post explicit approval later. An unwanted side-effect of importing unreviewed/unpolished/controversial src.rpm contents into CVS would be that observers on commits-list raise questions or even veto something. Hence it would be beneficial if an approval came early, and that's why I wrote "before or shortly after" above. Btw, making a package _build and work_ is your [the packager's] responsibility, not the reviewer's. Just as with upgrades, where nobody looks over your shoulder perhaps, _you_ receive the regression reports, the build failure logs, or nasty questions by fellow packagers, who point out packaging pitfalls or other oddities. > so I would > prefer to import a package into CVS as soon as: > 1) All legal issues or cleared, iow there are no legal issues > (remaining) > 2) There is someone who is willing to take on the role of (primary) > reviewer because he agrees the package would make a welcome addition > to FE. That doesn't contract with what I've written earlier. From mpeters at mac.com Fri Apr 29 16:42:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 29 Apr 2005 09:42:14 -0700 Subject: D1x license In-Reply-To: <20050429160831.GA6375@jadzia.bu.edu> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429143620.GA3034@jadzia.bu.edu> <1114786519.3333.42.camel@localhost.localdomain> <20050429160831.GA6375@jadzia.bu.edu> Message-ID: <1114792934.3990.8.camel@fc4t2.mpeters.local> On Fri, 2005-04-29 at 12:08 -0400, Matthew Miller wrote: > > Yeah, I know it's a pretty common restriction. But, if we want to move more > of Core to Extras (and I think pretty much everyone agrees we do), and make > Extras easily selected from anaconda, Extras effectively become part of the > basic distribution that vendors might want to actually provide. And having a > single package in Extras with this restriction would then basically restrict > all of Fedora. > No it doesn't. It just means vendors need to check which packages from extras they can (or can not) distribute before burning their CD/DVD set. However, putting that kind of stuff into rpm.livna.org and leaving extras with what is _truly_ freely redistributable makes it much easier. From mpeters at mac.com Fri Apr 29 16:51:51 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 29 Apr 2005 09:51:51 -0700 Subject: D1x license In-Reply-To: <427257B9.2060008@gmx.net> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> Message-ID: <1114793511.3990.18.camel@fc4t2.mpeters.local> On Fri, 2005-04-29 at 11:50 -0400, Michael Wiktowy wrote: > > I would think that that would be for someone who wants to sell Fedora > Extras CDs to worry about. > AFAIK, there is no charge for people accessing the Fedora Extras > repository so it could happily reside there. If someone wants to extend > the scope of Extras later into a commercial product, then they will have > to make some adjustments and know what they are doing. > Not putting this in just because someone may choose to come along and > try to commercialize Extras without putting any thought or work into > doing so seems silly to me. In this case sure - but the problem arises if you have libraries that other things in extras are linked against. Then the vendor has to remove the library, and rebuild any packages that are linked against it so that they now are not, and furthermore make sure nothing has been statically linked against it. This makes it a lot more work for someone who wants to sell CD/DVD sets - and there are some people doing it not for a profit motive, but because they want it to be freely and easily accessible to people without bandwidth and/or CD/DVD burners (or knowledge on how to burn - which a lot of people have trouble with). I don't sell extras currently, but I do sell core CD/DVD (and updates) for that purpose. I do plan to make extras available when Anaconda supports it (FC5 or 6), simply because it has some very useful apps that some people like (AbiWord, Gnumeric, Bluefish, Firestarter, Lyx, etc.). If I had to evaluate all the packages in extras, it won't be worth it for me. I want to know I can burn and distribute it as is without any _known_ to Fedora legal issues. Otherwise I just won't. Magazine distribution of Extras is probably the same way - editor isn't going to want to dig through what is restricted for him and what is not. From rc040203 at freenet.de Fri Apr 29 17:43:55 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Apr 2005 19:43:55 +0200 Subject: D1x license In-Reply-To: <1114792934.3990.8.camel@fc4t2.mpeters.local> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429143620.GA3034@jadzia.bu.edu> <1114786519.3333.42.camel@localhost.localdomain> <20050429160831.GA6375@jadzia.bu.edu> <1114792934.3990.8.camel@fc4t2.mpeters.local> Message-ID: <1114796635.24385.350.camel@mccallum.corsepiu.local> On Fri, 2005-04-29 at 09:42 -0700, Michael A. Peters wrote: > On Fri, 2005-04-29 at 12:08 -0400, Matthew Miller wrote: > > > > > Yeah, I know it's a pretty common restriction. But, if we want to move more > > of Core to Extras (and I think pretty much everyone agrees we do), and make > > Extras easily selected from anaconda, Extras effectively become part of the > > basic distribution that vendors might want to actually provide. And having a > > single package in Extras with this restriction would then basically restrict > > all of Fedora. > > > > No it doesn't. > It just means vendors need to check which packages from extras they can > (or can not) distribute before burning their CD/DVD set. > > However, putting that kind of stuff into rpm.livna.org and leaving > extras with what is _truly_ freely redistributable makes it much easier. I see 2 major problems: 1. Livna carries packages which potentially are lawful in the US, therefore, AFAIK it probably would be lawful to direct users there, ... 2. Livna doesn't use the FE infrastructure. As "non-free" doesn't necessarily mean "illegal", a FE/non-free (Non- free in the sense of non-FOSS compliant but legal) repository would make things even more easier and better maintainable. Ralf From skvidal at phy.duke.edu Fri Apr 29 18:07:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Apr 2005 14:07:07 -0400 Subject: D1x license In-Reply-To: <1114796635.24385.350.camel@mccallum.corsepiu.local> References: <4271DB7B.7080102@hhs.nl> <1114761505.17483.10.camel@fc4t2.mpeters.local> <4271EF49.90708@hhs.nl> <1114783738.3333.28.camel@localhost.localdomain> <20050429143620.GA3034@jadzia.bu.edu> <1114786519.3333.42.camel@localhost.localdomain> <20050429160831.GA6375@jadzia.bu.edu> <1114792934.3990.8.camel@fc4t2.mpeters.local> <1114796635.24385.350.camel@mccallum.corsepiu.local> Message-ID: <1114798027.22369.8.camel@cutter> > 1. Livna carries packages which potentially are lawful in the US, > therefore, AFAIK it probably would be lawful to direct users there, ... Keep in mind that it's not just the US people should be concerned with. It sounds like the EU and japan are going to be in equally bad shape w/i a year. -sv From mwiktowy at gmx.net Fri Apr 29 18:08:17 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Fri, 29 Apr 2005 14:08:17 -0400 Subject: D1x license In-Reply-To: <1114793511.3990.18.camel@fc4t2.mpeters.local> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> <1114793511.3990.18.camel@fc4t2.mpeters.local> Message-ID: <42727811.8080602@gmx.net> Michael A. Peters wrote: >On Fri, 2005-04-29 at 11:50 -0400, Michael Wiktowy wrote: > > > >>I would think that that would be for someone who wants to sell Fedora >>Extras CDs to worry about. >>AFAIK, there is no charge for people accessing the Fedora Extras >>repository so it could happily reside there. If someone wants to extend >>the scope of Extras later into a commercial product, then they will have >>to make some adjustments and know what they are doing. >>Not putting this in just because someone may choose to come along and >>try to commercialize Extras without putting any thought or work into >>doing so seems silly to me. >> >> > >In this case sure - but the problem arises if you have libraries that >other things in extras are linked against. > >Then the vendor has to remove the library, and rebuild any packages that >are linked against it so that they now are not, and furthermore make >sure nothing has been statically linked against it. > >This makes it a lot more work for someone who wants to sell CD/DVD sets >- and there are some people doing it not for a profit motive, but >because they want it to be freely and easily accessible to people >without bandwidth and/or CD/DVD burners (or knowledge on how to burn - >which a lot of people have trouble with). > >Magazine distribution of Extras is probably the same way - editor isn't >going to want to dig through what is restricted for him and what is not. > > Those are all very valid points but it comes down to a fair distribution of workload and availablility. If you want to prevent something that is not commercially redistributable from entering Extras in the first place, you make your life easier, make the person trying to contribute to Extra do extra work and make the package much less accessible to everyone who has the bandwidth to handle Extras over the internet. I have absolutely nothing against commercialization of updates/extras/alternative media, in fact I think that it serves a valuable niche. I don't think that life should be made more difficult for people who want to do that. However, I think that the workload should be biased towards the person making the profit from the workload and the availability be biased towards the majority. There is a middle ground that would likely make everyone's life easier. Ensuring clear and consistent marking of the license type in the rpm package info would make non-commercial variants much easier to filter out with a simple script. That would maximize the availability and not make things too onerous for someone wanting to rebundle for profit. It would also entail much clearer and detailed package submission guidelines than exist currently. But I understand those are a work in progress but I am not sure who is guiding that work. /Mike From toshio at tiki-lounge.com Fri Apr 29 18:36:59 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 29 Apr 2005 11:36:59 -0700 Subject: request for review: tre In-Reply-To: <1114291593.30784.22.camel@rydia.hardsun.net>; from a.kurtz@hardsun.net on Sat, Apr 23, 2005 at 02:26:33PM -0700 References: <1114291593.30784.22.camel@rydia.hardsun.net> Message-ID: <20050429113659.A15096@tiki-lounge.com> On Sat, Apr 23, 2005 at 02:26:33PM -0700, Aaron Kurtz wrote: > On Sat, 2005-04-23 at 07:21 -0400, Chris Ricker wrote: > > > > > > tre is primarily a POSIX-compliant regexp library, but with support for > > arbitrarily approximate matching. The package also includes agrep, a fuzzy > > grep built using this library. > > > > Anyone care to review / sponsor? > Just a first glance. You should have this:: URL: http://laurikari.net/tre/ Source0: http://laurikari.net/tre/tre-0.7.2.tar.bz2 Instead of this:: URL: http://laurikari.net/tre/tre-0.7.2.tar.bz2 Source0: tre-0.7.2.tar.bz2 -Toshio From dwmw2 at infradead.org Fri Apr 29 19:02:36 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 29 Apr 2005 20:02:36 +0100 Subject: Help wanted with converting 1 line asm i386->x86_64 In-Reply-To: <4272271C.8050208@hhs.nl> References: <4272271C.8050208@hhs.nl> Message-ID: <1114801357.27227.255.camel@hades.cambridge.redhat.com> On Fri, 2005-04-29 at 14:22 +0200, Hans de Goede wrote: > > Now the questions are: > -what symbol gets defined instead of __i386__ for x86_64 > -is the asm code correct for x86_64 You'll probably get away with it for x86_64 but it's definitely not going to work on PPC. It's also probably not actually having the desired effect even on i386, since it's not locking the bus. -- dwmw2 From ville.skytta at iki.fi Fri Apr 29 19:02:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 29 Apr 2005 22:02:38 +0300 Subject: Help wanted with converting 1 line asm i386->x86_64 In-Reply-To: <4272271C.8050208@hhs.nl> References: <4272271C.8050208@hhs.nl> Message-ID: <1114801358.16489.206.camel@bobcat.mine.nu> On Fri, 2005-04-29 at 14:22 +0200, Hans de Goede wrote: > -what symbol gets defined instead of __i386__ for x86_64 I tried to find out some time ago too, but couldn't find anything helpful. IIRC on FreeBSD __x86_64__ and __amd64__ get defined, but not on FC. Someone with a x86_64 box could maybe send the output of "cpp -dM /dev/null" for reference. From michal at harddata.com Fri Apr 29 19:03:45 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 29 Apr 2005 13:03:45 -0600 Subject: Help wanted with converting 1 line asm i386->x86_64 In-Reply-To: <4272271C.8050208@hhs.nl>; from j.w.r.degoede@hhs.nl on Fri, Apr 29, 2005 at 02:22:52PM +0200 References: <4272271C.8050208@hhs.nl> Message-ID: <20050429130345.D24215@mail.harddata.com> On Fri, Apr 29, 2005 at 02:22:52PM +0200, Hans de Goede wrote: > > Now the questions are: > -what symbol gets defined instead of __i386__ for x86_64 Hm, I used 'gcc -dumpspecs' for that in the past; in particular '*cpp_cpu' section. Now with gcc 3.4.3 I see there things which are not particularly informative. Does somebody know how to make gcc more forthcoming? It is always possible to try to guess if you do not have some other sources handy where such conditional compilation was already used. A short program which is using '#if defined(__x86_64__)' will show pretty quickly if such thing is really defined or not. Quite likely #if !defined(__x86_64__) #error "this is not defined" #endif may be good enough. Admittedly such "shoot-and-miss" approach is not the best one. > -is the asm code correct for x86_64 I do not think so but I do not really know. Michal From michal at harddata.com Fri Apr 29 19:09:49 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 29 Apr 2005 13:09:49 -0600 Subject: Help wanted with converting 1 line asm i386->x86_64 In-Reply-To: <1114801358.16489.206.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Fri, Apr 29, 2005 at 10:02:38PM +0300 References: <4272271C.8050208@hhs.nl> <1114801358.16489.206.camel@bobcat.mine.nu> Message-ID: <20050429130949.E24215@mail.harddata.com> On Fri, Apr 29, 2005 at 10:02:38PM +0300, Ville Skytt? wrote: > Someone with a x86_64 box could maybe send the output of > "cpp -dM /dev/null" for reference. That is a good idea. With "3.4.3 20050227 (Red Hat 3.4.3-22.fc3)" in this output there are things like #define unix 1 #define linux 1 #define __x86_64 1 #define __amd64 1 #define __x86_64__ 1 #define __amd64__ 1 and a bunch of other things like __FLT_MAX_EXP__ Michal From mpeters at mac.com Fri Apr 29 19:23:29 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 29 Apr 2005 12:23:29 -0700 Subject: D1x license In-Reply-To: <42727811.8080602@gmx.net> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> <1114793511.3990.18.camel@fc4t2.mpeters.local> <42727811.8080602@gmx.net> Message-ID: <1114802610.3990.42.camel@fc4t2.mpeters.local> On Fri, 2005-04-29 at 14:08 -0400, Michael Wiktowy wrote: > > There is a middle ground that would likely make everyone's life easier. > Ensuring clear and consistent marking of the license type in the rpm > package info would make non-commercial variants much easier to filter > out with a simple script. Or such packages could go in rpm.livna.org. Putting them in rpm.livna.org IMHO is a much better solution - because there can not be scenarios where packages that are otherwise free link against them, and thus are not distributable. Let's say the MPEG consortium grants permission for mp3 decoding for non commercial use (I think they actually have, or at least have stated they will not go after people who use it for non commercial use). Then a mp3 decoding library is written (or license on libmad changed). That library is then used in a media player in Extras. By not being able to distribute the mp3 decoding library, the packager would also have to remove (or rebuild) any media players that link against that library (much like core builds sox w/o lame and libmad). This can become a problem if there are many such libraries and many apps that use them. I don't object to these kinds of packages existing, my main system is full of them - divx, for example - closed source, free for non commercial use, I have it installed and have software (gstreamer plugin) linked against it, and I use it quite a bit. But I personally feel Extras should be safe for individuals and corporations alike to use as a source of software that truly is free. Keeping them in rpm.livna.org means that there will not be any extras packages that depend upon them, and it also pushes a search for truly free packages to fill needs. For example, a company doing video work and wants to use truly free software will use theora because the other video codecs are in livna, not core or extras, indicating there are legal or distribution issues with them. rpm.livna.org is just as yummable as Extras, packages with patent or other license issues can go there (assuming they are approved) and are not any less available than if they were in Extras. The only difference is that someone who burns an Extras DVD is not going to have to look through the packages themselves, simply do not distribute livna packages. From kaboom at oobleck.net Fri Apr 29 19:26:37 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 29 Apr 2005 15:26:37 -0400 (EDT) Subject: request for review: tre In-Reply-To: <20050429113659.A15096@tiki-lounge.com> References: <1114291593.30784.22.camel@rydia.hardsun.net> <20050429113659.A15096@tiki-lounge.com> Message-ID: On Fri, 29 Apr 2005, Toshio Kuratomi wrote: > Just a first glance. You should have this:: > URL: http://laurikari.net/tre/ > Source0: http://laurikari.net/tre/tre-0.7.2.tar.bz2 > > Instead of this:: > URL: http://laurikari.net/tre/tre-0.7.2.tar.bz2 > Source0: tre-0.7.2.tar.bz2 Fixed, thanks later, chris From ville.skytta at iki.fi Fri Apr 29 20:04:41 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 29 Apr 2005 23:04:41 +0300 Subject: ITP: trac, clearsilver In-Reply-To: <1112605778.5531.4.camel@otto.amantes> References: <1112289776.31596.87.camel@bobcat.mine.nu> <1112605778.5531.4.camel@otto.amantes> Message-ID: <1114805081.16489.210.camel@bobcat.mine.nu> On Mon, 2005-04-04 at 11:09 +0200, Thomas Vander Stichele wrote: > Hey Ville, > > try > http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora- > stable/clearsilver-0.9.8-0.fdr.1.3/ > http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora- > stable/python-trac-0.8-0.fdr.1.3/ Argh, I completely missed your reply, so went ahead and packaged them myself some time ago. Lightly tested, but seems to work. http://cachalot.mine.nu/3/SRPMS.extras/clearsilver-0.9.14-0.2.src.rpm http://cachalot.mine.nu/3/SRPMS.extras/trac-0.8.1-0.1.src.rpm No rush in getting these to Extras right now, but if someone insists to review, go right ahead... From ville.skytta at iki.fi Fri Apr 29 20:12:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 29 Apr 2005 23:12:27 +0300 Subject: General gcc4.0 porting guide In-Reply-To: <20050429135604.17409f66@nausicaa.camperquake.de> References: <20050429135604.17409f66@nausicaa.camperquake.de> Message-ID: <1114805547.16489.216.camel@bobcat.mine.nu> On Fri, 2005-04-29 at 13:56 +0200, Ralf Ertzinger wrote: > For example, what is the "right" way to deal with this: [...] Help would be welcome also with freedroidrpg: https://bugzilla.redhat.com/152498 http://sourceforge.net/tracker/index.php?func=detail&aid=1165999&group_id=54521&atid=474016 From mwiktowy at gmx.net Fri Apr 29 20:31:51 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Fri, 29 Apr 2005 16:31:51 -0400 Subject: D1x license In-Reply-To: <1114802610.3990.42.camel@fc4t2.mpeters.local> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> <1114793511.3990.18.camel@fc4t2.mpeters.local> <42727811.8080602@gmx.net> <1114802610.3990.42.camel@fc4t2.mpeters.local> Message-ID: <427299B7.90102@gmx.net> Michael A. Peters wrote: >On Fri, 2005-04-29 at 14:08 -0400, Michael Wiktowy wrote: > > > >>There is a middle ground that would likely make everyone's life easier. >>Ensuring clear and consistent marking of the license type in the rpm >>package info would make non-commercial variants much easier to filter >>out with a simple script. >> >> > >Or such packages could go in rpm.livna.org. >Putting them in rpm.livna.org IMHO is a much better solution - because >there can not be scenarios where packages that are otherwise free link >against them, and thus are not distributable. > > I think you are talking apples and oranges here. In my mind, "some restrictions on the distribution of packages" does not equal "totally illegal to distribute in some countries with screwed up IP laws". AFAIK, livna.org is intended for the latter and probably can't even by linked to directly in the Fedora installer for fear of contributory-yadda-yadda-yadda (sorry for the legal jargon ;]). While I totally agree with you that allowing non-commercial restrictions on packages in Extras adds complexity to the repackaging of Extras for commercial purposes. I don't think that the aversion to that complexity justifies the complete exclusion of those packages from Extras. In any case, looking at http://fedoraproject.org/wiki/PackagingGuidelines , it would seem that written permission to distribute the binary datafile *without restriction* is needed from the author anyways. So to comply with that condition either, D1x engine is put in Extras and links to code obtained from non-Extras sources (with a stub package to link to if complete dependency closure is required within Extras+Core ... I didn't find that restriction anywhere) or permission is obtained from the author to distribute the binary datafile without restriction (including non-commercial restrictions I would assume). So unless there is willingness to modify the guidelines, it appears black and white as it stands. /Mike From mattdm at mattdm.org Fri Apr 29 20:38:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 29 Apr 2005 16:38:59 -0400 Subject: D1x license In-Reply-To: <427299B7.90102@gmx.net> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> <1114793511.3990.18.camel@fc4t2.mpeters.local> <42727811.8080602@gmx.net> <1114802610.3990.42.camel@fc4t2.mpeters.local> <427299B7.90102@gmx.net> Message-ID: <20050429203859.GA16543@jadzia.bu.edu> On Fri, Apr 29, 2005 at 04:31:51PM -0400, Michael Wiktowy wrote: > While I totally agree with you that allowing non-commercial restrictions > on packages in Extras adds complexity to the repackaging of Extras for > commercial purposes. I don't think that the aversion to that complexity > justifies the complete exclusion of those packages from Extras. What are "commercial purposes"? Can the package be used as part of my job that makes money? What if I work for a non-profit? What if I don't? What if I do consulting using my Fedora Extras box, and a utility I use is linked against library with this restriction? What if I'm working on some grant-funded project that uses this software, and the results of that work gets spun off into a startup company? Both the GPL and the BSD licenses avoid all of this, for good reason. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From mwiktowy at gmx.net Fri Apr 29 21:17:43 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Fri, 29 Apr 2005 17:17:43 -0400 Subject: D1x license In-Reply-To: <20050429203859.GA16543@jadzia.bu.edu> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> <1114793511.3990.18.camel@fc4t2.mpeters.local> <42727811.8080602@gmx.net> <1114802610.3990.42.camel@fc4t2.mpeters.local> <427299B7.90102@gmx.net> <20050429203859.GA16543@jadzia.bu.edu> Message-ID: <4272A477.2080306@gmx.net> Matthew Miller wrote: >On Fri, Apr 29, 2005 at 04:31:51PM -0400, Michael Wiktowy wrote: > > >>While I totally agree with you that allowing non-commercial restrictions >>on packages in Extras adds complexity to the repackaging of Extras for >>commercial purposes. I don't think that the aversion to that complexity >>justifies the complete exclusion of those packages from Extras. >> >> > >What are "commercial purposes"? Can the package be used as part of my job >that makes money? What if I work for a non-profit? What if I don't? What if >I do consulting using my Fedora Extras box, and a utility I use is linked >against library with this restriction? What if I'm working on some >grant-funded project that uses this software, and the results of that work >gets spun off into a startup company? > >Both the GPL and the BSD licenses avoid all of this, for good reason. > > > Poor choice of words on my part. The specific "purpose" was "distribution" for the context of my discussion. I certainly wouldn't extend my defense to any other non-commercial restrictions on use or products of use. Looking back that the license quoted in the original email, it looks like the binary data file is less encumbered than the source code of the engine wrt to your point about usage restrictions. I am curious now if some closed-source games have such usage restrictions on them (I don't think that I have ever made it through completely reading one of those EULAs). It would probably make gaming competitions using those games illegal. /Mike From skvidal at phy.duke.edu Fri Apr 29 21:36:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Apr 2005 17:36:46 -0400 Subject: extras status report In-Reply-To: <1114670208.16489.108.camel@bobcat.mine.nu> References: <1114669238.20429.8.camel@cutter> <1114670208.16489.108.camel@bobcat.mine.nu> Message-ID: <1114810606.22369.18.camel@cutter> On Thu, 2005-04-28 at 09:36 +0300, Ville Skytt? wrote: > On Thu, 2005-04-28 at 02:20 -0400, seth vidal wrote: > > > I've been kinda silent for the past week b/c I've been busy and > > frustrated - I just wanted to give everyone a heads up as to what I've > > been doing and what the reason is I've not built the set of packages on > > the wiki build request pages. > > Thanks for the update and the hard work. > > However, before the "make build" stuff is available, would it be > possible to build at least sylpheed-claws for both FC3 and devel? It's > marked as a security update in Wiki. > > If you're willing to do more builds manually at this time, wxGTK for > devel looks like the next important one in the queue to me. I'll build all the things that are important this weekend and try to finish out the xmlrpc stuff on 'make build'. on the plus side I got past that bug I mentioned earlier and am working on the xmlrpc stuff to talk to the ppc build box. -sv From mpeters at mac.com Fri Apr 29 21:58:32 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 29 Apr 2005 14:58:32 -0700 Subject: D1x license In-Reply-To: <427299B7.90102@gmx.net> References: <4271DB7B.7080102@hhs.nl> <427257B9.2060008@gmx.net> <1114793511.3990.18.camel@fc4t2.mpeters.local> <42727811.8080602@gmx.net> <1114802610.3990.42.camel@fc4t2.mpeters.local> <427299B7.90102@gmx.net> Message-ID: <1114811912.3990.53.camel@fc4t2.mpeters.local> On Fri, 2005-04-29 at 16:31 -0400, Michael Wiktowy wrote: > > I think you are talking apples and oranges here. In my mind, "some > restrictions on the distribution of packages" does not equal "totally > illegal to distribute in some countries with screwed up IP laws". AFAIK, > livna.org is intended for the latter and probably can't even by linked > to directly in the Fedora installer for fear of > contributory-yadda-yadda-yadda (sorry for the legal jargon ;]). There are at least some packages in livna bugzilla that do not have legal reasons. The madwifi driver for example, it's not illegal to distribute - but it does contain a binary HAL taints the kernel (the binary HAL does not use any kernel code and is OS independent) >From what I understand (I wasn't active in Fedora at the time, I was doing stuff mostly in LFS) livna exists as a result of the Fedora.us and Red Hat merge - packages in Fedora.us that did not meet Red Hat's requirements were farmed out to rpm.livna.org. Most of those were patent issue packages, but I don't believe it is limited to that. From j.w.r.degoede at hhs.nl Fri Apr 29 22:22:38 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 30 Apr 2005 00:22:38 +0200 Subject: Help wanted with converting 1 line asm i386->x86_64 In-Reply-To: <1114801357.27227.255.camel@hades.cambridge.redhat.com> References: <4272271C.8050208@hhs.nl> <1114801357.27227.255.camel@hades.cambridge.redhat.com> Message-ID: <4272B3AE.8040901@hhs.nl> David Woodhouse wrote: > On Fri, 2005-04-29 at 14:22 +0200, Hans de Goede wrote: > >>Now the questions are: >>-what symbol gets defined instead of __i386__ for x86_64 >>-is the asm code correct for x86_64 > > > You'll probably get away with it for x86_64 but it's definitely not > going to work on PPC. Thats ok, the package is exclusive arch i386, ia64 and x86_64. > It's also probably not actually having the desired > effect even on i386, since it's not locking the bus. Er well it has worked on i386 without problems for years afaik. Regards, Hans From mattdm at mattdm.org Sat Apr 30 02:44:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 29 Apr 2005 22:44:15 -0400 Subject: extras status report In-Reply-To: <1114670208.16489.108.camel@bobcat.mine.nu> References: <1114669238.20429.8.camel@cutter> <1114670208.16489.108.camel@bobcat.mine.nu> Message-ID: <20050430024415.GA28589@jadzia.bu.edu> On Thu, Apr 28, 2005 at 09:36:48AM +0300, Ville Skytt? wrote: > If you're willing to do more builds manually at this time, wxGTK for > devel looks like the next important one in the queue to me. Is this going to be wxGTK 2.6? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ivazquez at ivazquez.net Sat Apr 30 03:13:58 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Apr 2005 23:13:58 -0400 Subject: extras status report In-Reply-To: <20050430024415.GA28589@jadzia.bu.edu> References: <1114669238.20429.8.camel@cutter> <1114670208.16489.108.camel@bobcat.mine.nu> <20050430024415.GA28589@jadzia.bu.edu> Message-ID: <1114830838.7966.2.camel@ignacio.ignacio.lan> On Fri, 2005-04-29 at 22:44 -0400, Matthew Miller wrote: > On Thu, Apr 28, 2005 at 09:36:48AM +0300, Ville Skytt? wrote: > > If you're willing to do more builds manually at this time, wxGTK for > > devel looks like the next important one in the queue to me. > > Is this going to be wxGTK 2.6? No, still 2.4.2 atm. But at least it builds with gcc4 now. -- 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 mattdm at mattdm.org Sat Apr 30 03:31:03 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 29 Apr 2005 23:31:03 -0400 Subject: extras status report In-Reply-To: <1114830838.7966.2.camel@ignacio.ignacio.lan> References: <1114669238.20429.8.camel@cutter> <1114670208.16489.108.camel@bobcat.mine.nu> <20050430024415.GA28589@jadzia.bu.edu> <1114830838.7966.2.camel@ignacio.ignacio.lan> Message-ID: <20050430033103.GA30431@jadzia.bu.edu> On Fri, Apr 29, 2005 at 11:13:58PM -0400, Ignacio Vazquez-Abrams wrote: > > > If you're willing to do more builds manually at this time, wxGTK for > > > devel looks like the next important one in the queue to me. > > Is this going to be wxGTK 2.6? > No, still 2.4.2 atm. But at least it builds with gcc4 now. FWIW, . But maybe that's best left for FC5. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From ryo-dairiki at mbm.nifty.com Sat Apr 30 05:06:20 2005 From: ryo-dairiki at mbm.nifty.com (=?ISO-2022-JP?B?GyRCQmdOT048GyhC?=) Date: Sat, 30 Apr 2005 14:06:20 +0900 Subject: I'm looking for someone to sponsor me. Message-ID: <4273124C.3040306@mbm.nifty.com> Hi, I'm Ryo Dairiki, a packager of SCIM projects. (If you don't know SCIM, please visit http://www.scim-im.org/) Now I'm thinking of adding the packages to Fedora Extras. I've already finished "Fedora Individual Contributor Lisence Agreement" and made a request for membership in the cvsextras. Now I'm looking for a person who sponsor me. If you sponsor me, please give me a mail. Regards, Ryo Dairiki From j.w.r.degoede at hhs.nl Sat Apr 30 10:24:08 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 30 Apr 2005 12:24:08 +0200 Subject: Imported to CVS, review requested: Glide3 In-Reply-To: <20050429120923.0fd0a318@python2> References: <42712EA1.2050401@hhs.nl> <20050429120923.0fd0a318@python2> Message-ID: <42735CC8.60208@hhs.nl> Matthias Saou wrote: > Hi, > > I just tried to recompile it for FC Development x86_64 and got this error : > > [...] > gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations - > ffast-math -DBIG_OPT -Wall -DGLIDE_LIB -DGLIDE3 -DGLIDE3_ALPHA -DH3 - > DGLIDE_PACKET3_TRI_SETUP=1 -DUSE_PACKET_FIFO=1 -DGLIDE_HW_TRI_SETUP=1 - > DFX_GLIDE_NAPALM=1 -DFX_GLIDE_H5_CSIM=1 -DGLIDE_PLUG -DGLIDE_SPLASH - > DFX_STATIC_BUILD -DGLIDE_INIT_HWC -DGLIDE_USE_C_TRISETUP -I../../../../h5/ > glide3/src -I../../../h5/incsrc -I../../../../h5/incsrc -I../../../../h5/ > minihwc -I. -I../../../../swlibs/fxmemmap -I../../../../swlibs/fxmisc - > I../../../../swlibs/newpci/pcilib -I../../../../swlibs/texus2/lib -O2 -g - > pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -O6 -Wno- > unknown-pragmas -Wno-unused-value -Wno-unused -Wno-missing-noreturn -Wp,- > MD,.deps/gsplash.pp -c ../../../../h5/glide3/src/gsplash.c -fPIC -DPIC - > o .libs/gsplash.o In file included from ../../../../h5/glide3/src/ > gsplash.c:170: ../../../../h5/glide3/src/fxglide.h:2104:4: error: #error > "P6 Fencing code needs to be added for this compiler" make[3]: *** > [gsplash.lo] Error 1 make[3]: Leaving directory `/usr/src/rpm/BUILD/Glide3/ > build-5/h5/glide3/src' > > Not sure what should be done... > > Matthias > Ok, This and a bunch of other stuff should be fixed in CVS now, please try the current CVS version. Thanks & Regards, Hans From rdieter at math.unl.edu Sat Apr 30 13:41:55 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 30 Apr 2005 08:41:55 -0500 Subject: use of gtk-update-icon-cache? In-Reply-To: <1114769268.8958.20.camel@thl.ct.heise.de> References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> Message-ID: Thorsten Leemhuis wrote: > I planed this mail for the weekend after a bit more investigation in > this area, but while on topic I better start now: > Am Freitag, den 29.04.2005, 11:36 +0200 schrieb F. Kooman: >>%post >># update icon themes >>touch %{_datadir}/icons/hicolor >>if [ -x /usr/bin/gtk-update-icon-cache ]; then >> /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor >>fi > AFAIK we also need to do this in %post and %postun in every FC4/devel > extras-package that installs something into "%{_datadir}/icons/*/" so > the cache files found there. IMO, this is getting friggin rediculous adding so much crud in %%post/%%postun to *so many* packages. Can't this task be relagated to a nightly cron job instead (controlled by whatever owns /usr/bin/gtk-update-icon-cache, of course)? -- Rex From ville.skytta at iki.fi Sat Apr 30 13:54:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 30 Apr 2005 16:54:56 +0300 Subject: use of gtk-update-icon-cache? In-Reply-To: <1114769268.8958.20.camel@thl.ct.heise.de> References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> Message-ID: <1114869296.16489.241.camel@bobcat.mine.nu> On Fri, 2005-04-29 at 12:07 +0200, Thorsten Leemhuis wrote: > +Requires(post): gtk2 >= 2.6 [...] > +touch --no-create %{_datadir}/icons/hicolor || : > +if [ -x /usr/bin/gtk-update-icon-cache ]; then > + gtk-update-icon-cache -q %{_datadir}/icons/hicolor || : > +fi gtk-update-icon-cache will only be run if it exists, so the hard dependency should be dropped. At least I'm not comfortable adding such a dep to packages that don't need gtk2 otherwise; there were for example quite a few KDE packages in your list. Further, because of the "|| :", the above could be simplified into: touch --no-create %{_datadir}/icons/hicolor && \ gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2>/dev/null || : Yes, this would hide possible errors from gtk-update-icon-cache, but do we care about those anyway? On the other hand, gtk-update-icon-cache has the "-f" option. Is using it the same thing as the touch+update-without-f above? So even more simplified version could be: gtk-update-icon-cache -qf %{_datadir}/icons/hicolor 2>/dev/null || : From paul at all-the-johnsons.co.uk Sat Apr 30 16:57:15 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 30 Apr 2005 17:57:15 +0100 Subject: clamav - really odd problem Message-ID: <1114880235.19568.2.camel@localhost> Hi, For some reason, unless I have clamav switched off, my machine totally fails to boot. It fails to start a clamav component (either clvmd or clamav-milter) and then just stops booting. The keyboard is still live (I can reboot from the keyboard). Strange or what! Anyone else seeing this? TTFN Paul FC4t2 kernel 2.6.11-1.1275_FC4 -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 mpeters at mac.com Sat Apr 30 17:31:50 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 30 Apr 2005 10:31:50 -0700 Subject: use of gtk-update-icon-cache? In-Reply-To: References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> Message-ID: <1114882311.3445.1.camel@laptop.mpeters.local> On Sat, 2005-04-30 at 08:41 -0500, Rex Dieter wrote: > > IMO, this is getting friggin rediculous adding so much crud in > %%post/%%postun to *so many* packages. Can't this task be relagated to > a nightly cron job instead (controlled by whatever owns > /usr/bin/gtk-update-icon-cache, of course)? Correct me if I'm wrong (and I often am) - but I think this effects the usability directly after installing the package, in which case waiting for a cron job to run is not ideal - especially for people with laptops who have chosen to disable anacron. From nphilipp at redhat.com Sat Apr 30 17:57:06 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 30 Apr 2005 19:57:06 +0200 Subject: clamav - really odd problem In-Reply-To: <1114880235.19568.2.camel@localhost> References: <1114880235.19568.2.camel@localhost> Message-ID: <1114883826.8773.2.camel@gibraltar.stuttgart.redhat.com> On Sat, 2005-04-30 at 17:57 +0100, Paul wrote: > For some reason, unless I have clamav switched off, my machine totally > fails to boot. It fails to start a clamav component (either clvmd or > clamav-milter) and then just stops booting. The keyboard is still live > (I can reboot from the keyboard). > > Strange or what! > > Anyone else seeing this? Might be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156355 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 fedora at leemhuis.info Sat Apr 30 18:17:45 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 30 Apr 2005 20:17:45 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> Message-ID: <1114885066.5465.11.camel@notebook.thl.home> Am Samstag, den 30.04.2005, 08:41 -0500 schrieb Rex Dieter: > Thorsten Leemhuis wrote: > > Am Freitag, den 29.04.2005, 11:36 +0200 schrieb F. Kooman: > >>%post > >># update icon themes > >>touch %{_datadir}/icons/hicolor > >>if [ -x /usr/bin/gtk-update-icon-cache ]; then > >> /usr/bin/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor > >>fi > > AFAIK we also need to do this in %post and %postun in every FC4/devel > > extras-package that installs something into "%{_datadir}/icons/*/" so > > the cache files found there. > > IMO, this is getting friggin rediculous adding so much crud in > %%post/%%postun to *so many* packages. Can't this task be relagated to > a nightly cron job instead (controlled by whatever owns > /usr/bin/gtk-update-icon-cache, of course)? Yes, I also would like a working solution where such a scriptlet is not needed. But that's imo a decision that should be done in core. And in core this scriptlet was added to a lot of packages one or two month ago. There was a short discussion on this topic (cron job or other solutions to avoid scriptlet) then, too. Without a better solution iirc. -- Thorsten Leemhuis From fedora at leemhuis.info Sat Apr 30 18:30:17 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 30 Apr 2005 20:30:17 +0200 Subject: use of gtk-update-icon-cache? In-Reply-To: <1114869296.16489.241.camel@bobcat.mine.nu> References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> <1114869296.16489.241.camel@bobcat.mine.nu> Message-ID: <1114885817.5465.19.camel@notebook.thl.home> Am Samstag, den 30.04.2005, 16:54 +0300 schrieb Ville Skytt?: > On Fri, 2005-04-29 at 12:07 +0200, Thorsten Leemhuis wrote: > > > +Requires(post): gtk2 >= 2.6 > [...] > > +touch --no-create %{_datadir}/icons/hicolor || : > > +if [ -x /usr/bin/gtk-update-icon-cache ]; then > > + gtk-update-icon-cache -q %{_datadir}/icons/hicolor || : > > +fi > > gtk-update-icon-cache will only be run if it exists, so the hard > dependency should be dropped. I'm was think about that also and I'm all for it. > At least I'm not comfortable adding such > a dep to packages that don't need gtk2 otherwise; there were for example > quite a few KDE packages in your list. You're right of course. As I said, it was a quick lookup of packages that might show this problem. And maybe at that moment I forgot the other major desktop environment ;-) > Further, because of the "|| :", the above could be simplified into: > > touch --no-create %{_datadir}/icons/hicolor && \ > gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2>/dev/null || : > > Yes, this would hide possible errors from gtk-update-icon-cache, but do > we care about those anyway? > > On the other hand, gtk-update-icon-cache has the "-f" option. Is using > it the same thing as the touch+update-without-f above? So even more > simplified version could be: > > gtk-update-icon-cache -qf %{_datadir}/icons/hicolor 2>/dev/null || : Yeah, it seems you're right. Or are there opinios against this solution? -- Thorsten Leemhuis From paul at all-the-johnsons.co.uk Sat Apr 30 19:26:19 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 30 Apr 2005 20:26:19 +0100 Subject: clamav - really odd problem In-Reply-To: <1114883826.8773.2.camel@gibraltar.stuttgart.redhat.com> References: <1114880235.19568.2.camel@localhost> <1114883826.8773.2.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1114889179.19568.9.camel@localhost> On Sat, 2005-04-30 at 19:57 +0200, Nils Philippsen wrote: > On Sat, 2005-04-30 at 17:57 +0100, Paul wrote: > > For some reason, unless I have clamav switched off, my machine totally > > fails to boot. It fails to start a clamav component (either clvmd or > > clamav-milter) and then just stops booting. The keyboard is still live > > (I can reboot from the keyboard). > > > > Strange or what! > > > > Anyone else seeing this? > > Might be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156355 Looks possible. I did try it without rhgb on the kernel boot line which is how I found clamav was causing hiccups. TTFN Paul -- "In an urban society, everything connects. Each person's needs are fed by the skills of many others. Our lives are woven together in a fabric. But the connections that make society strong also make it vulnerable." - Threads, BBC-TV 1984 -------------- 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 rdieter at math.unl.edu Sat Apr 30 20:01:41 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 30 Apr 2005 15:01:41 -0500 Subject: use of gtk-update-icon-cache? In-Reply-To: <1114882311.3445.1.camel@laptop.mpeters.local> References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> <1114882311.3445.1.camel@laptop.mpeters.local> Message-ID: Michael A. Peters wrote: > On Sat, 2005-04-30 at 08:41 -0500, Rex Dieter wrote: > > >>IMO, this is getting friggin rediculous adding so much crud in >>%%post/%%postun to *so many* packages. Can't this task be relagated to >>a nightly cron job instead (controlled by whatever owns >>/usr/bin/gtk-update-icon-cache, of course)? > > > Correct me if I'm wrong (and I often am) - but I think this effects the > usability directly after installing the package, AFAIK, you are wrong. It'll still work, it just won't get gain the speed benefits of the pre-built cache. Similar analogies to why prelink isn't re-run after every binary/library install... -- Rex From kaboom at oobleck.net Sat Apr 30 20:30:09 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 30 Apr 2005 16:30:09 -0400 (EDT) Subject: Request for Review: hula In-Reply-To: <4270630D.8060108@iprone.com> References: <200504152033.23317.hula-kevin@iprone.com> <4270630D.8060108@iprone.com> Message-ID: On Thu, 28 Apr 2005, Kevin Gray wrote: > Just another request for review of hula. I didnt give a link to the actual > package last time. It can be downloaded at http://files.iprone.com/. Just some random thoughts from looking at the package: * usually the /usr/lib/lib*.so links go in the -devel package and only the lib*.so.* stuff in the runtime package * change the init script to # chkconfig: - 86 16 Just because someone installed the program doesn't mean it should be autorun at boot, especially when it opens up half the ports on the system and runs as root :-) * really should be built to run as a non-root user ./autogen.sh --with-user=hula add the hula user and group in %pre * a lot of the paths look odd. /var/netmail? /var/mdb? And none of that is in the spec %files? * cert generation seems broken. If your IP is 1.2.3.4, the generated cert is for host 4.3.2.1 * shipping with a default admin account and password (admin / hula) is not a good idea later, chris From bugs.michael at gmx.net Sat Apr 30 20:41:49 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Apr 2005 22:41:49 +0200 Subject: Request for Review: hula In-Reply-To: References: <200504152033.23317.hula-kevin@iprone.com> <4270630D.8060108@iprone.com> Message-ID: <20050430224149.6a8e9a92.bugs.michael@gmx.net> On Sat, 30 Apr 2005 16:30:09 -0400 (EDT), Chris Ricker wrote: > On Thu, 28 Apr 2005, Kevin Gray wrote: > > > Just another request for review of hula. I didnt give a link to the actual > > package last time. It can be downloaded at http://files.iprone.com/. > > Just some random thoughts from looking at the package: > > * usually the /usr/lib/lib*.so links go in the -devel package and only the > lib*.so.* stuff in the runtime package See earlier "Request for Review: hula" thread: https://www.redhat.com/archives/fedora-extras-list/2005-April/msg00442.html From mpeters at mac.com Sat Apr 30 21:03:25 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 30 Apr 2005 14:03:25 -0700 Subject: use of gtk-update-icon-cache? In-Reply-To: References: <1114767381.4827.7.camel@dilithium.bromstraat.net> <1114769268.8958.20.camel@thl.ct.heise.de> <1114882311.3445.1.camel@laptop.mpeters.local> Message-ID: <1114895005.3243.2.camel@laptop.mpeters.local> On Sat, 2005-04-30 at 15:01 -0500, Rex Dieter wrote: > > AFAIK, you are wrong. It'll still work, it just won't get gain the > speed benefits of the pre-built cache. Similar analogies to why prelink > isn't re-run after every binary/library install... OK - then it's a maintenance issue and doesn't need to be done during install of the package, and probably shouldn't be (less you do the better imho).